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. > 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. 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. 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]. 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. Cheers, FJP [1] Which IMO makes the "legacy" issue somewhat less important than it would otherwise be. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
