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

Re: Standardizing use of kernel hook scripts

On Thu, Apr 02 2009, Frans Pop wrote:

> Tyler MacDonald wrote:
>> Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
>>> > On Wed, Apr 01 2009, Frans Pop wrote:
>>> [make-kpkg]
>>> >> But is anyone still using it? Is there any current reason to support
>>> >> it
>> Well, there's still some kernel options that are immutable and
>> multiple choice. And there's always people that want to optimize. Out of
>> laziness (or maybe having better things to do? <g>) my current setups
>> aren't make-kpkg'ed, but it would depress me if, after using make-kpkg
>> for years and years, I wanted to use it again one day and found that it
>> didn't work anymore.
> Tyler,
> Same point as made in reply to Darren: we're not trying to find out if 
> anyone is using make-kpkg, but whether anyone is using hook scripts that 
> rely on the second parameter that gets passed to them.
> And, more in general, whether that second parameter is still needed/useful 
> in a new API for calling the hook scripts.

        While in no way stopping you from doing the survey, I am
 wondering what purpose it serves. If looking for popularity, we have
 heard from people who actually use kernel package. How many users are
 there of the upstream make deb? How many of that subset of users
 actually use the hook directories at all?  How many users of official
 kernel images use the hook directories?

        Also, looking forward, instead of back, kernel-package has been
 moving towards reducing complkexity of the maintianer scripts, at the
 same time increasing the flexibility of the site admin to affect the
 install process, so all past is not prologue here.

        And if we are trying to design an API, the question best asked
 is not popularity, but features that we wish to support. I do not want
 to be caught in the juvenile discussion of "My method is more popular
 than yours, nyah nyah".  The feature in question here is:
  -- Do we want to cater to sites that do not want /boot as the place
     they place kernel images? Do we want to allow kernel images mounted
     off a usb key, for instance, into a different location than /boot?
     Or mounted off a file system that truncates the length of the file
     names? (How things boot would be up to the site admin -- assume
     that they have made it bootable)

        If we do, then a second argument specifying the location of the
 image is a decent, tested, and working solution.

        If the project decides that we should only ever support kernel
 images with the full, default name in /boot, then so be it. But _that_
 is what should be under discussion, not how popular things are.

The only difference between a rut and a grave is their dimensions.
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: