(dropping ltsp as the list is moderated) Manoj Srivastava wrote: >> My patch series for the upstream kernel contains roughly the following >> changes: [...] > Where are these patches?
Only just submitted: http://marc.info/?l=linux-kbuild&m=123861445626856&w=2 maks has also submitted a set of patches: http://marc.info/?l=linux-kbuild&m=123851278623264&w=2 Some discussion on those: http://marc.info/?l=linux-kbuild&m=123860208704620&w=2 >> ISSUES >> ====== >> Parameters passed to hook scripts >> --------------------------------- >> Is anything other than the kernel version really needed? > > Yes, since in the old days the image location could be changed, > by passing a parameter to make-kpkg. I think this feature is used, > since it was put into kernel-package by request. But is anyone still using it? Is there any current reason to support it (i.e. is there any reason to _add_ support for it in deb-pkg or in whatever the kernel team is planning)? >> Maintainer script parameters >> ---------------------------- >> Currently maintainer script parameters are not passed on to the hook >> scripts, but IMO they could be very useful, for example: a bootloader >> update only needs to be run on package removal, but not on purge. >> >> Given the previous point I think adding them to the parameters passed to >> the hook scripts is not a good option. I therefore propose to instead >> export them in a standard environment parameter. Proposal: >> export DEB_MAINT_PARAMS="$@" > > Hmm. That would mean that the first argument is the name of the > script, then? No. $@ starts at $1, not at $0. In the hook scripts I currently use I do: version=$1 set -- $DEB_MAINT_PARAMS >> Execution order of hook scripts >> ------------------------------- >> Both initramfs-tools and ltsp-client currently just dump a script in the >> hook dirs without any naming convention. If many packages were to do >> that, chaos would be a guaranteed result. >> >> IMO scripts should have standardized names starting with numbers to >> regulate execution order. Ranges should be reserved, for example: >> - early scripts 00-19 >> - initrd generation 30-49 >> - bootloader update 50-69 >> - late scripts 80-99 >> >> Use of new numbers by packages should probably be coordinated by the >> kernel team. > > If this were to become policy, I would say _all_ stakeholders > should be involved, not just the official kernel packages, and that > means not shutting out end users who compile their own kernel image > debs. Agreed. That's why I said "coordinated" and not "mandated". However, IMO it's probably not unreasonable to expect stakeholders to be subscribed to d-kernel. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
