On 29 April 2012 14:26, Colin Guthrie <mag...@colin.guthr.ie> wrote: >> According to your detailed changelog in the previous commit, >> I actually doubt this is for drakxservices. >> If it's about the "first boot", then this should have been logged in >> the installer NEWS > > Hmmm, if you say so. I just figured that anything that runs when stage1 > and stage2 are not involved is not anything to do with the "installer". > > Conceptually, I can see how first boot could be considered part of the > "install" process, so feel free to correct as you see fit seeing as this > somewhat subjective distinction is not something I have any real desire > to master or argue over :) I'll just try and guess better next time :p
Well it was obvious that it cannot be about drakxservices since the context was "first boot" and drakxservices isn't in the game at this stage. I though you was speaking about services set up by the installer for the first boot. But now, with the actual bug report, I see it was affecting the harddrake service. So it's in the right NEWS file but the description is wrong, it should speak about service_harddrake then since drakxservice hasn't the same timeout as harddrake and it's the later that has the issue not the former. In that case, the $::isStandalone won't be enought as it will be set for both harddrake service & drakxservices. We could set another global variable in harddrake ($::booting ?) and test for it in services.pm. WDYT?
