On Thu, Jun 18 2009, Colin Watson wrote:
> On Wed, Jun 17, 2009 at 03:54:10PM +0200, Felix Zielcke wrote:
>> 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,
While there would likely have been no user changes lost in this
specific case, it would have broken all extant installations.
> # but it was never done for some reason that is mysterious to me.
Because at that point, the kernel image postinst would likely
have broken -- kernel-package 10.051 was the first that generated
postinst files that worked with non-absolute paths.
> /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.
Actually, this is no longer accurate: the official kernel images
have their own home brewed maintainer scripts, and are independent of
the kernel-package package. Additionally, kernel images created by
make deb-pkg in upstream Makefiles have yet another set of maintainer
scripts. Yes, we now have three different ways that kernel image
packages may be created, and three different sets of maintainer
scripts. And the upgrade path might need to weave back and forth
between images from these pedigrees.
> 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.
Which set of kernel packaging people would be implementing this?
The kernel team, me, or some person who has influence over at LKML?
I'll be happy to do that, (well, not happy, exactly, but ...). but
there is no guarantee it will reach all the Debian
installations. Indeed, all three kernel image creation mechanisms will
have to implement the fix, in order for all configuration files to be
affected.
Frankly, I htink the best way moving forward is for grub to put
a file in /etc/kernel/*.d/ directories, and for grub isntaller not to
create /etc/kernel-img.conf.
manoj
--
QOTD: All I want is more than my fair share.
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
