On Thu, Apr 02 2009, Frans Pop wrote:
> Tyler MacDonald wrote:
>> Darren Salt <li...@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.
manoj
--
The only difference between a rut and a grave is their dimensions.
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
