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

Re: Standardizing use of kernel hook scripts



On Wed, Apr 01 2009, Frans Pop wrote:
> On Wednesday 01 April 2009, maximilian attems wrote:
>> On Wed, 25 Mar 2009, Frans Pop wrote:

>
> The default for deb-pkg should IMO remain /etc/kernel in order not to 
> break things for existing users. If you move to /lib and users want to 
> follow, they can use my mechanism.

        The situation is similar for kernel-package. The installed base
 means that moving to /lib would be suboptimal, and I I do think that
 actions taken when kernel packages are installed should be overridable
 by the site admin. 

>> > New initramfs-tools hook scripts uses the kernel version and includes
>> > a hack that tests if $2 is defined to avoid running with pre-squeeze
>> > kernels and make-kpkg kernels. Not ideal...
>>
>> why not ideal?
>
> Because it relies on a very specific, largely accidental difference 
> between implementations. What if we decide that we _do_ want to use a 
> second parameter for something.
> My suggestion set the origin of a build in an envvar is more flexible.

        Since the kernel-package will now stop running initramfs in the
 postinst, and will rely on a hook script to generate or not generate an
 initramfs, we have the need for a script that handles _all_ kernels
 that need an initramfs, no matter how the .deb was created, and which
 also can be told _not_ to create an initramfs, if there is no need.

        We need to have a sane, documented, and stable means for doing
 so. 

>> > 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.
>>
>> nah not very useful,
>
> Eh? Then how are you going to ensure update-initramfs runs before 
> update-grub? Alphabetically they are in the wrong order.

        I also think we need some kind of policy guideline for naming
 scripts, and I agree in principle with the ouline Frans has proposed
 above.


>> enforcing correct file name ending with .sh might be more worthwhile.
>
> That's discouraged by policy (except maybe for files that are sourced).

        We can look to /etc/init.d for inspiration here.

>> > To conffile or not to conffile
>> > ------------------------------
>> > If I'm correct neither initramfs-tools nor ltsp-client currently
>> > defines the hook scripts as conffiles. This is both good and bad.
>> >
>> > - good: the hook script are removed when the package is removed which
>> >   avoids the problem that it could get run after removal, but before
>> > purge - bad: user changes in the scripts get lost on package upgrades
>>
>> no conffile.
>> users shouldn't care to much about these details.

> Most users probably won't care, but I still think you underestimate this. 
> Especially if make-kpkg and official kernels are going to use the same 
> hook dirs.

        I think that if we should stick to /etc (and I think we should),
 we have no option: these files will be configuration files, even if
 they are not conffiles, and user input will have to be preserved. There
 is no reason not to follow policy here.

>
>> i'd prefer a /lib location and if you still see it worthwile
>> for powerusers the /etc conffile?!
>
> If there is a clear mechanism for overruling the standard scripts that 
> could work.

        I suppose I can live with e /lib location, as long as the
 overruling by the local admin is easy.

>> > - possibly be responsible for creating/updating symlinks, although
>> > that's always a tough one as you might want symlinks updated for
>> > official kernels but not for custom built ones (or use different
>> > symlinks for custom kernels); the suggested "source" envvar could
>> > help there

        I think this should be a local decision. The symlink issue has
 had some very strong opinions expressed over the years.

>> > - provide a shell library file with functions to implement some of the
>> > ideas mentioned above 
>>
>> no extra package should be needed
>
> That's a rather unsubstantiated opinion. Could you elaborate how you'd 
> solve the points I listed here?

        I can see a whole set of differing solution, perhahs offered by
 a set of conflicting packages, here.

>> linux-2.6 make deb-pkg should have it's postinst fixed and should work
>> standalone that is the main point and greatest bonus.
>
> I don't understand what you're saying here. I actually _like_ the simple 
> hook script mechanism of deb-pkg as it allows me to very simply have 
> different things done for different architectures.
>
> What's broken about the deb-pkg postinst?
> What do you mean by "standalone"?

        We also can not close the door on other mechanisms that help end
 users create image packages. Heck, if we can have qtcoreutils, we can
 have qt-make-kpkg.

        manoj

-- 
Sanity and insanity overlap a fine grey line.
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: