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
