[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

Please reply to debian-kernel only.

On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote:
> On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote:
> > The environment variable DEB_MAINT_PARAMS will contain
> > the arguments given to the kernel maintainer script, single-quoted.
> Is this environment variable provided by the maintainer scripts
> that come with kernel image packages created by "make deb-pkg"?
> (I honestly don't know.  I've never used "make deb-pkg".)

It has done since 2.6.31, though without single-quotes.  I'll note that
they may or may not be quoted, and recommend how to use this variable.

> > 5. Kernel and initramfs builder packages must not invoke boot loaders
> > except via hooks.  If /etc/kernel-img.conf contains an explicit
> > 'do_bootloader = yes', kernel package maintainer scripts should warn
> > that this is now ignored.
> At the risk of flogging a dead horse, I would prefer to see
> "do_bootloader = yes" supported until Squeeze+1, both by the
> kernel maintainer scripts and by "update-initramfs -u", particularly
> since we are so close to a freeze.

The release team has stated we are not close to a freeze.  So we have a
little time to sort this out.

> But if
> you're going to drop support for it in Squeeze, then yes,
> a warning message is necessary.  Both the kernel maintainer scripts
> *and* "update-initramfs -u" *must* issue a warning message if they
> find "do_bootloader = yes" specified in /etc/kernel-img.conf.
> In fact, since the default value is "yes", they should issue
> the warning message unless do_bootloader is *explicitly* set
> to no.

I can put a one-time warning into linux-base.  But the default for
squeeze must be 'no'.  It should not be necessary to create
/etc/kernel-img.conf at all in squeeze.

> > 6. The installer must not define do_bootloader, postinst_hook or
> > postrm_hook in /etc/kernel-img.conf.
> Doesn't this conflict with point 4 (a)?

Not at all.  This means postinst_hook and postrm_hook are now strictly
for use by the user.


Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: