Bug#533287: debian-policy: please clarify 10.7.4
On Wed, Jun 17, 2009 at 03:54:10PM +0200, Felix Zielcke wrote:
> For example we grub/grub2 maintainers have the problem that some people
> still have /sbin/update-grub in their /etc/kernel-img.conf.
> grub-legacy has a wrapper to warn about this since etch, but we recently
> got a bug report in grub2 who had it still in place (#500631).
> After I asked in #debian-devel my solution to this problem was to just
> abort in the preinst with an error message.
> Then I noticed #470894 where Colin Watson wanted to
> edit /etc/default/grub inside of grub-installer.
> And there I told him that I'm unsure if policy allows this and told him
> my solution to our problem.
Let's discount the question of /etc/default/grub; it's not at issue
here, and the solution you're using now for it is not questionable
AFAICS.
> In message #36 [0] and #46 [1], he told me that we should either keep it
> as an symlink or just edit automatically /etc/kernel-img.conf
> /etc/kernel-img.conf is edited by grub-installer automatically to add
> update-grub to it.
My concern is essentially, without intending offence to anyone involved,
that we look stupid doing it the way we were doing it. :-) I'll quote my
mail to debian-boot:
# I'm sorry to have to say this, but the kernel-img.conf /sbin/update-grub
# migration has been a hopelessly confusing mess. Please don't use it as
# an example of anything except how *not* to do things.
#
# Either /sbin/update-grub should have continued to be supported forever
# as a symlink without warnings, or (preferably) something should have
# taken care of detecting the situation and rewriting the configuration
# file automatically. Robert even suggested a way to do this in #361929,
# but it was never done for some reason that is mysterious to me.
# Complaining about the situation and aborting is the worst of both
# worlds; it often merely throws users into confusion, or at best leaves
# them cursing about how Debian didn't just sort out its own mistakes
# rather than making users take care of it by hand.
#
# I understand, of course, that there are all sorts of reasons why these
# sorts of things happen at the time; but if you look at the change as a
# whole then it was very clearly far from optimal.
/etc/kernel-img.conf is a weird case. To start with, it's initially
created by the installer (base-installer) and the update-grub line is
added by another part of the installer (grub-installer). Obviously the
installer can't own a configuration file permanently, so we say that the
kernel owns it because it's the primary consumer (and indeed
historically it was using it before the installer did anything with it).
Its format is clearly documented in kernel-img.conf(5).
Of course, though, the kernel is not a single package, but a succession
of packages with different names and very similar maintainer scripts
generated by kernel-package, so its upgrade path is not simple.
Furthermore, the requirement that update-grub be called without an
explicit path (or at least not as /sbin/update-grub) comes from the grub
package and is due to changes there; if the grub package insists on a
change to a configuration file, as it did, then I do feel that it should
be its responsibility to put its own house in order.
(Normally I would say that a package should fix up its own mistakes, but
in this case the mistaken entry in the configuration file comes from
grub-installer, which is part of the installer and so can't do anything
to fix up its mistakes on upgrade.)
I would not object to the kernel packaging making this change instead,
but of course we are then reliant on people actually upgrading to newer
kernels, which is in practice not something that happens quite so
reliably as normal package upgrades. People hang back on the kernel for
all kinds of reasons. But, nevertheless, perhaps a kernel packaging
person (Manoj?) could speak up and say whether they'd be willing to have
the kernel fix up old /etc/kernel-img.conf files that mention
/sbin/update-grub.
The worst possible solution, in my book, is for grub to abort in its
preinst and force the user to make the change by hand. If we end up
doing that then we have put policy, or perhaps a failure to agree on
implementation, ahead of the user. From the user's point of view, Debian
(collectively) made this mistake and Debian should fix it up rather than
bothering them about it. The warning was faintly ridiculous in the same
way, and I certainly heard friends of mine who were upgrading from older
versions of Debian object that we should just have fixed the file rather
than complaining at them about its contents.
I'm not too surprised that the recommendation I made to have grub edit
/etc/kernel-img.conf rather than abort if it's wrong is contentious, I
suppose. I don't think the situation is so clear that it is manifestly
wrong - I certainly felt it to be justifiable, and I think the situation
is distinctly muddy - though I concede it may not be the best possible
answer.
> But then I don't know what grub-installer should do for #470894, except
> we provide a update-etc-default-grub script which just runs sed over it,
> just to compl with policy.
As I say, I don't think that's at issue here, and I think we have
arrived at the best solution for management of /etc/default/grub. If the
grub maintainers are content to declare that grub-installer may edit one
of their configuration files (i.e. it's already by definition using the
recommended lack-of-interface extended to it :-) ), then I don't see why
anyone should object. Part of the installer's work often ends up being
to edit configuration in some places for which no general interface is
necessary, and that seems fine to me as long as it's with the consent of
the owners of the configuration file.
> 10.7.4 says:
> The owning package should also provide a program that the other packages
> may use to modify the configuration file.
>
> The related packages must use the provided program to make any desired
> modifications to the configuration file.
>
> These 2 sentences together don't make sense for me.
> They should provide a program that other packages -may_ use and then the
> next sentence it's a _must_.
If a program is provided for modifying the configuration file, then it
must be used.
The "may" in the first paragraph is not, I believe, a must/should/may
kind of "may", but more an idiomatic "that the other packages are then
able to use" kind of sense. Manoj's rewording is better, I think.
--
Colin Watson [cjwatson@debian.org]
Reply to: