Bug#934463: initscripts: consider taking over hwclock policy machinery

Andreas Henriksson andreas at fatal.se
Mon Aug 12 21:37:13 BST 2019


On Mon, Aug 12, 2019 at 07:31:03PM +0000, Dmitry Bogatov wrote:
> Yes. Help is definitely needed. I guess, order of actions is following:
>  * you upload util-linux=<no-hwclock> version and breaks with current
>    version of initscripts

Not sure, I'll have to think on, what the right relation is here.
Normally you'd make the old carrier Depends: on the new version of the new
carrying package, but that's something we likely want to avoid here.
As you suggested Breaks might thus be the correct choice.

The (new) util-linux package should likely also include some
rm_conffile maintainerscripts to make sure the util-linux version of the
conffiles don't linger as unowned files on systems that don't have
initscripts installed. I'm not sure how to avoid util-linux removing the
conffiles when/if they get taken over by initscripts though (hopefully
it 'just works', but definitely needs to be investigated to make sure).

>  * I include files into initscripts and upload initscripts=<hwclock> and
>    conflict with util-linux << <no-hwclock>.

The (new) initscripts package should definitely have:
Replaces: util-linux << <new-revision>~
Breaks: util-linux << <new-revision>~

(Replaces is needed for overwriting files from another package on
upgrade and Replaces also always goes hand in hand with either of
Breaks (normally), Conflicts or a (versioned) Depends.)

> This is how things usually done on non-conffiles. Are there additional
> complications with conffiles?

Yes, there are many gotchas with conffiles. Extensive testing is needed.
I'd say the two main things to test is that there are no confusion with
unmodified files and also that local modifications (incl. removed  files
staying removed) are properly transfered on upgrade. Special care then
also needs to persist until after Bullseye release with further changes
to avoid breaking any of the previous before everyone has upgraded.
(Fortunately skipping releases aren't supported on Debian, but for the
benefit of potential downstream distros you might want to ensure this
for a longer time and hold back on modifications that might break the
upgrade/handover of the conffiles.)

Andreas Henriksson

More information about the Debian-init-diversity mailing list