On Wed, Apr 01 2009, Frans Pop wrote:
> Manoj Srivastava wrote:
>> On Wed, Apr 01 2009, Frans Pop wrote:
>>> (i.e. is there any reason to _add_ support for it in deb-pkg or in
>>> whatever the kernel team is planning)?
>>
>> I think so. If we do standardize on /etc/kernel/*.d directories
>> as the place where kernel packages will look into to run scripts, then
>> the scripts in that location should have a common API. Since we have an
>> installed base, and there is going to be continued support for this
>> feature by the current debian end user kernel packaging tool, we can't
>> just drop the old api and scripts.
>
> Eh, different _existing_ tools already diverge. I agree on the need for a
> common API, or at least ensuring that there is legacy support. (After
> all, that is why I sent my initial mail).
> But I see no reason why the "the make-kpkg way" should be elevated to that
> standard API without any discussion.
We have had make-kpkg be the way we did kernel images since
circa '96. There is a a lot of installed base there -- or so we should
assume, unless we know differenty. I'll be willing to change things if
you can show that there is not much of an installed base -- I hate
assuming there is none, and yanking the rug out from under the users.
>
>> Also, this proposal should go through the vetting of the primary
>> place we make technical policy for Debian, which is the debian-policy
>> mailing list. Since this is going to require interaction between all
>> kinds of packages in providing scripts for kernel package handling, the
>> standards we create for determining when these scripts are triggered,
>> how parameters are passed in, is precesily the kind of thing that
>> policy is created for.
>
> I have no problems with that.
>
>> Traditionally, you passed --initrd to make-kpkg to trigger the
>> call to initrd; but now that we are thinking of different drivers than
>> make-kpkg, how is this information stored and sent to the script?
>
> Which only worked because initrd generation was/is coded in the
> postinst itself and not in a postinst hookscript.
Right. But functionality is desirable -- regardless of how it
was implemented in the past.
This is the functionality we want:
o) Some kernels configurations are such that an initrd is rewquired --
all file systems, for example, can be put into modules
o) Other configurations do not use modules -- and a lot of kernel
hackers do not. It improves boot times, etc. For these cases, an
initrd is not required, and should not be created.
o) The same amchine may want to use a lean, experimental kernel,
and fall back on the distro default in case of failure.
Now, if you can devise a mechanism where we can distinguish
between these kernel images, and have an initrd either created, or not
created, i'll comply with whatever protocol you come up with.
>
> To be honest, I don't really see why k-p supports hook scripts at all,
> given that it already does everything that's normally needed in the
> regular postinst it generates.
But it does not. There is no way for the kernel package postinst
to work with grub, without using the hook scripts.
Also, the mechanisms built in are constricting, and people are
using different mechanisms for booting, and taking other action when a
boot component is changed.
Keeping track of 11 architectures, different boot mechanisms,
initrd generation schemes, and other actions people want to take, was
taking a toll on the code complexity and bugginess.
You wanna know when I started supporting the hook directories?
,----
| * Added support for hook directories. Apart from hook variables that the
| local admin may set, there are a set of directories where packages, or
| the local admin, may drop in script files. The directories are
| - /etc/kernel/preinst.d/,
| - /etc/kernel/postinst.d/,
| - /etc/kernel/prerm.d/, and
| - /etc/kernel/postrm.d/.
| If they exists, the kernel-image package shall run a run-parts program
| over the directory, giving the version being installed or removed as
| an argument, in the corresponding phase of installation or
| removal. Since these directories do not exist by default, this should
| have no impact on current installations.
|
| -- Manoj Srivastava <sriva...@debian.org> Fri, 8 Oct 2004 14:05:06 -0500
|
`----
That is 4.5 years ago. This is long before the kernel team
started using this. Thne builddeb code was incorporated ito the
mainline kernel sources in 2005-04-16.
> For that reason I would guess that the number of users that actually
> use the existing hook script mechanism in make-kpkg is very, very low
> [1].
Your false assumption kinda renders this null and void -- every
grub user already uses the hook mechanism, and k-p has had support for
this for over 4 years.
> And that is a completely different model from what the deb-pkg target
> does and what's now being considered by the kernel team. Unifying
> those separate models is always going to be painful.
The /etc/kernel support has been in kernel-package far before it
was considered by the kernel team, and indeed, contemporaneous with the
dpkg-pkg code. So I don't think kernel-package is a newcomer in the
/etc/kernel/*.d arena.
manoj
--
Uneven economic and political development is an absolute law of
capitalism. Nicolai Lenin
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-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
