Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Tue, 15 Jun 2010 23:25:45 -0400 (EDT), Ben Hutchings wrote:
> On Tue, 2010-06-08 at 09:43 -0400, Stephen Powell wrote:
>>
>> do_bootloader = yes
>>
>> in /etc/kernel-img.conf means "run the historic boot loader for this platform".
>> For the i386 platform (and amd64) the historic boot loader is lilo. For
>> the s390 platform, that boot loader is zipl. The kernel maintainer scripts
>> for the s390 platform still specify zipl as the boot loader
>>
>> my $loader = "zipl"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>>
>> so that
>>
>> do_bootloader = yes
>>
>> in /etc/kernel-img.conf will work. The kernel maintainer scripts for i386 and amd64
>> for Lenny and beyond specify a null string. That is inconsistent. It should specify
>>
>> my $loader = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>>
>> for consistency between platforms.
>> [...]
>
> This code and the file /etc/kernel-img.conf are vestiges of
> kernel-package which are gradually being removed from the official
> kernel packages. Therefore I don't think we should reinstate this idea
> of the default loader but we should change the code so that it doesn't
> silently fail if do_loader is set and loader is not.
Well, I agree that the maintainer script should not silently fail.
But removing support for the historic boot loader actually makes the
official stock Debian kernel image package maintainer scripts *more*
like kernel-package, not less. To be more precise, it makes them
more like the *Squeeze* version of kernel-package. The maintainer
scripts which get packaged with a kernel image package created by
make-kpkg under Squeeze and later releases no longer perform *any*
post installation activities. They do not create an initial RAM file
system (even if the --initrd option was specified on the make-kpkg
command line), they do not maintain symbolic links (even if
"do_symlinks = yes" is specified in /etc/kernel-img.conf), and they
do not run the historic boot loader (even if "do_bootloader = yes" is
specified in /etc/kernel-img.conf). If you want any of these things
done, then either the user or an installed package must provide hook
scripts to accomplish this. The maintainer scripts packaged
with kernel image packages created by make-kpkg under Lenny and
previous releases still do all these things.
I can maybe accept your proposal for Squeeze. But for Lenny, I believe
that the maintainer scripts should be changed back they way they
were. In other words,
my $loader = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
should be set in the maintainer scripts. After all, Lenny does
not have the generalized hook script environment that Squeeze does.
I believe that this bug is severe enough to warrant inclusion of the
fix in stable-proposed-updates.
>
> All packages that need to react to kernel installation or removal should
> install appropriate hook scripts in the directories under /etc/kernel
> instead of relying on specific support in the kernel maintainer scripts.
>
Again, I can maybe accept that argument for Squeeze, but not for Lenny.
However, to be consistent, if you're going to leave "my $loader" set to the null
string in i386 and amd64 kernel maintainer scripts, you should also set
it to the null string for s390 kernel maintainer scripts.
This will affect the s390-tools package, which includes the zipl boot
loader for the s390 platform; so I'm copying them in on this. If your
proposed solution goes through, they will need to create some kind of
hook script too, or at least document the need for one. And so will lilo.
And when we're all done, that leaves us with one foot in the old way
of doing things and one foot in the new way of doing things. The initial
RAM file system will still be created automatically, symlinks will still
be maintained (if requested in /etc/kernel-img.conf), but the historic
boot loader will not be run.
I would rather see the the stock kernel
maintainer scripts do none of the above, like the new kernel-package,
or all of the above, like the historic stock kernel maintainer scripts.
And this is pretty late in the Squeeze development cycle to start making
design changes. We're getting pretty close to a freeze, are we not?
It sure seems to me like a one-line change in the kernel maintainer
scripts is a much faster and much simpler fix, not to mention more
consistent. The maintainer scripts' support for the historic boot
loader should be retained, in my opinion, at least for Squeeze. Then,
if you want to change the design of how kernel maintainer scripts
work, that can be done in Squeeze+1.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: