Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
Hi,
]] Colin Watson
> I could arrange for the relevant grub2 postinst scripts to remove
> /etc/default/grub.d/init-select.cfg entirely when appropriate conditions
> apply. In addition to a self-defence argument, this is further
> justified by the fact that grub2 now provides a similar facility of its
> own as of 2.02~beta2-20: if other init daemons are installed, then
> grub-mkconfig generates additional menu items for them (although there
> are no arrangements to migrate the default choice from
> /etc/default/init). This would still violate policy §10.7.3/10.7.4,
> although it seems to be the favoured option of the debian-devel thread,
> and it is the least bad option I can see so far.
I think this would be ok, see below.
[...]
> Policy does not at present contemplate the situation of an obsolete
> *package* with configuration files whose presence causes grave-severity
> problems for another package. Should it do so? We might, for instance,
> grant a package that is being extended by configuration files from some
> other package some additional authority to clean up problems caused by
> that, or perhaps make some general provisions about this quite common
> kind of configuration file extension interface. Of course we wouldn't
> want to suggest that packages could play core wars with each other in
> the archive.
I think a package that provides an extension interface (as you do)
should be able to police the use of those extension points in the cases
where there are (effectively unfixable) bugs or abuses of those
extension points.
I think extending policy with wording in this direction would be fine,
but I also think that you don't need to hold up making your change for
the policy change to go in (at least once the CTTE issues a
recommendation).
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: