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

Re: Forthcoming changes in kernel-package



Hi,

        A few hours ago, a new version of kernel-package was uploaded to
 Experimental.  This is a major change, the new kernel-package is far
 more nimble, more flexible, and supports people who make a minor change
 to a kernel, or who update the kernel sources (via git or otherwise),
 and want a minimal, simple, recompile. 

 79 files changed, 1776 insertions(+), 3706 deletions(-)

        The full NEWS.Debian file is appended below, but I'll highlight
 the major differences: This version does not support the official
 images (which is OK, since the kernel  team thinks kernel-package is
 broken anyway, and have been deprecating it for a few years now), it
 does not run a bootloader, or manage symlinks, or create an init ram fs
 for you -- since the policies governing these actions were becoming too
 rigid, and had to cater to the lowest common denominator.

        Instead, the package comes with example scripts that can be
 dropped into /etc/kernel/*.d directories to do all that, and more (you
 can change the number of symlinks you keep,  for example). Now you can
 add actions to {pre,post}{inst,rm} stages of the package installation or
 removal, independently, for image, header, source, and doc packages.

        More importantly, the initramfs scripts provided work with the
 make-kpkg images as well as the official images, and are thus better
 than the script shipped with initramfs-tools themselves, as they offer
 a super set of functionality.

        This version of kernel-package also demonstrates how the
 postsinst script communicates with the initramfs scripts so that no
 initramfs is generated in case you do not want it (I personally compile
 all modules in my non-laptop kernel, and thus do not need an
 initramfs).

        I have not yet seeded the  env with the maintainer script
 parameter arguments, but I'll put in what Frans suggested unless there
 are objections.

        Please take this for a spin. Kick the tires. I need helpe from
 people who run Xen machines, since  I do not use Xen, and would like to
 make the Xen images work better.

        manoj

kernel-package (12.001) experimental; urgency=low

  * This is a major change in functionality; do not upgrade unless you are
    prepared for the changes required on target machines.
  * make-kpkg removes and re-creates ./debian on every invocation

    This does make the kernel-package far more nimble; we now offer less
    surprise to users who did not expect stampts that the kernel-packagge
    used to not do duplicate work. Now, if you edit a couple of files in
    the kernel source, and run make-kpkg, the kernel will build as
    expected. There are no more "version mismatch" errors, and the kernel
    version can be modified using localconfig as one desires. With this,
    kernel-package can rountinely be used to build kernels out of the git
    tree.

    The con is that we no longer cater to official kernels, or to anyone who
    expected content in ./debian to persist. At some point, there are plans
    to implement an overlay directory that will shadow
    /usr/share/kernel-package/ruleset, but that is not yet implemented.
  * Get rid of the facility to patch kernel sources

    The patch the kernel facility was adding complexity, and failing to
    provide the flexibility required for a generic patching facility. It used
    to be useful at one point, but in the modern parlance, witht he
    widespread use of distribute version control systems, and various
    facilities to manage source and patch them, the built in version was
    clunky.  This means the --added-patches option of make-kpkg is gone,
    the work-around is to prepare the kernel sources _before_ calling
    make-kpkg. 
  * Remove special case code for official kernels

    For the longest tine (well, ever since Herbert Xu too over building
    kernel images from me), kernel-package has carried specal case code
    for official images. This has caused some problems, recently, since
    the need to preserve ./debian has caused no end of problems when the
    version changed out from under ./debian, or when people wanted to edit
    a file and expected kernel-package to do a minimal recompile.

    However, sometime in the Etch release cycle, the kernel team
    deprecated kernel-package as the means of building official kernels,
    and therefore, a full release cycle later, we can get rid of the
    special case rules used for official packages. Also, this allows us to
    drop ./debian at teh drop of a hart, and recreate it with an version
    that reflects the current state of the kernel sources.
  * No longer ship header debs that create symbolic links in /usr/src,
    instead, ship an example shell script that replicated the old
    behaviour. This script can then be deployed on the target machines,
    and could be a part of a locally created kernel configuration package,
    if one needs to deploy the same behavior across a cluster of
    machines. 
  * Image postinst no longer runs a boot loader

    Note that this was already the case for grub, one of the more popular
    boot loaders.
  
    Now that we have a mechanism for running arbitrary scripts when the
    image packages are manipulated, we can stop embedding the boot loader
    actions in the package itself. This means that lilo, elilo, etc will
    no longer be run directly by the post isnt, and all the code related
    to detecting the boot loader, managing the configuration, and adding
    bits about bootloader documentation is all removed from the
    postinst. This allows the image package to be more flexible, since the
    end user is no longer restricted to the actions encoded in the image
    package. This is a fairly large change. 
  * The postinst no longer manipulates symlinks
  
    This is a shift from previous behaviour. Any symbolic link
    manipulation must now be done with hook scripts in /etc/kernel/*.d
    directories.
  
    Firstly, modern boot loaders scan the boot directory for kernel
    images, and the user no longer has to code in the path to the symbolic
    links that the kernel image package used to manipulate.

    Secondly, hardcoding the behaviour into the postinst made for a very
    rigid policy; and user wanted more flexibility than that. There is an
    example shipped with the package that shows a more flexible scheme
    that kept two symbolic links for version 2.4 kernels, and two symbolic
    links for 2.6 kernels; it can be easily modified to keep two links for
    2.9 kernels and two links for 2.8 kernels, or one of each, or whatever
    the user wants. 
  * The image postinst no longer runs the initramfs creation
    commands. Instead, there are example scripts provided that will
    perform the task. These scripts will work for official kernel images
    as well.


-- 
How gaily a man wakes in the morning to watch himself keep on
dying. Henry S. Haskins
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: