On Fri, May 31, 2013 at 06:16:26PM -0000, Colin Watson wrote:
> The general approach more or less makes sense to me, but a few things:
> * Yes, we'll need corresponding changes to the installer; unfortunately
> this is one of the things that's duplicated between d-i and ubiquity,
> so changes need to be in both clock-setup and ubiquity.
> * We'll need to think about upload coordination. You have a version
> guard, but what about the overlap case with a daily build where an
> older installer installs a newer initscripts? That suggests to me
> that you shouldn't write to /etc/init/hwclock.override or
> /etc/init/hwclock-save.override if they already contain UTC settings;
> I think if we changed the installer first to handle either old or
> new, and then changed sysvinit with that refinement, then that would
> work.
Ok. Should I prepare the changes to clock-setup and ubiquity?
> * I don't quite understand what "sed -i -e's/^UTC=.*/UTC=yes/'
> /etc/default/rcS" is for. Is that so that dpkg conffile replacement
> works? Would it be better to forcibly remove the option in the
> postinst, instead or perhaps as well? Editing conffiles is of course
> always a bit scary, so I suppose go with whatever approach
> initscripts has historically taken here ...
This is to suppress the wrong conffile replacement prompt, yes, by ensuring
that the copy of the file on disk doesn't have any spurious delta caused by
the UTC setting that we're moving out of the way. I'm confident that this
part of the code is doing the right thing, neither incorrectly losing any
user preferences nor mangling the file in a way that will *cause* conffile
prompts incorrectly on upgrade. (This is a sed to UTC=yes, rather than a
removal, because that ensures it matches the interim version of the conffile
as shipped in the package currently in saucy, giving the correct results for
both pre-saucy and saucy upgrades.)
On Fri, May 31, 2013 at 06:16:26PM -0000, Colin Watson wrote:
> The general approach more or less makes sense to me, but a few things:
> * Yes, we'll need corresponding changes to the installer; unfortunately
> this is one of the things that's duplicated between d-i and ubiquity,
> so changes need to be in both clock-setup and ubiquity.
> * We'll need to think about upload coordination. You have a version hwclock. override or hwclock- save.override if they already contain UTC settings;
> guard, but what about the overlap case with a daily build where an
> older installer installs a newer initscripts? That suggests to me
> that you shouldn't write to /etc/init/
> /etc/init/
> I think if we changed the installer first to handle either old or
> new, and then changed sysvinit with that refinement, then that would
> work.
Ok. Should I prepare the changes to clock-setup and ubiquity?
> * I don't quite understand what "sed -i -e's/^UTC= .*/UTC= yes/'
> /etc/default/rcS" is for. Is that so that dpkg conffile replacement
> works? Would it be better to forcibly remove the option in the
> postinst, instead or perhaps as well? Editing conffiles is of course
> always a bit scary, so I suppose go with whatever approach
> initscripts has historically taken here ...
This is to suppress the wrong conffile replacement prompt, yes, by ensuring
that the copy of the file on disk doesn't have any spurious delta caused by
the UTC setting that we're moving out of the way. I'm confident that this
part of the code is doing the right thing, neither incorrectly losing any
user preferences nor mangling the file in a way that will *cause* conffile
prompts incorrectly on upgrade. (This is a sed to UTC=yes, rather than a
removal, because that ensures it matches the interim version of the conffile
as shipped in the package currently in saucy, giving the correct results for
both pre-saucy and saucy upgrades.)