Re: [gentoo-genkernel] Re: [RFC] Genkernel4 and Geninitramfs plan

[Amadeusz Żołnowski]

Quoting Sebastian Pipping (2012-09-09 19:21:23)
> On 09/09/2012 02:46 PM, Amadeusz Żołnowski wrote:
> > Geninitramfs is going to be extracted not earlier than Genkernel4 is
> > usable with Dracut to avoid synchronization work between
> > Geninitramfs and Genkernel3.
>
> I don't get that point, to be honest.  What is the problem and how
> does pushing the spliut further way help about it?

It helps that you don't care about Genkernel4 and Geninitramfs yet until
Genkernel4 is ready for users.

1) I implement Genkernel4 working with Dracut (might take some time)
2) Genkernel4 is ready for use

Until now Genkernel3 development is not interfered.

3) Genkernel3 development is frozen (only bug fixes)
4) Genkernel3 is moved, as I have described earlier, to Geninitramfs
   (this is going to be quick)
5) I make Genkernel4 support Geninitramfs (this is going to be quick)

There's no need for any wrapper.


> One thing missing in the migration: does geninitramfs keep using
> /etc/genkernel.conf ?  If so, how do we handle that?  if not, how do
> we migrate smoothly?

No, geninitramfs would use /etc/geninitramfs.conf, of course.


> > Genkernel4 is going to be rewritten from scratch in Bash4 and
> > possibly with some help of Python if necessary.
>
> Unlike with init scripts, there is no need for using shell scripting
> here, right?  If so, let's stick to Python >=2.6 only, if just for
> argparse alone.  Bash is one of genkernel's current issues in my
> opinion.

What Genkernel does is mostly calling shell commands.  Bash4 is the best
tool for this task if used correctly.  I'd use Python for helper tools
only if implementing something in Bash4 is PITA.


> > 02. Select version
> >
> > a) local
> >
> > User selects one of versions listed with "list -l" with arguments
> > "select -l <version>/<position of version on the list>".  The check
> > if sources still exist is done and the choice is remembered.
> >
> > b) remote
> >
> > User selects one of versions listed with "list -r" which doesn't
> > exist in /usr/src with arguments "select -r <version>/<position of
> > version on the list>".  It is checked if this particular version
> > could be downloaded and the choice is remembered.
>
> These are feature additions, if I am not mistaken.  Sounds good for
> later.

Do you mean the remote stuff?  Yes, possibly I'll implement that later.
And this is where Python might become handy.


> > 07. Build kernel and modules
> >
> > Runs "make" with CFLAGS, LDFLAGS, and JOBS given by user (in config
> > file).
>
> The question of building as root or non-root by our own Tobias
> Klausmann pops into my mind:
> <http://blog.i-no.de//archives/2012/07/index.html#e2012-07-04T19_28_32.txt>

Thanks.  I'll take that into account.


> > 10. Build initramfs
> >
> > An initramfs is going to be build either by Dracut or by
> > Geninitramfs.  I'd like to avoid using command line options of
> > Genkernel to pass to Geninitramfs or Dracut therefore Geninitramfs
> > or Dracut config is going to be used only.
>
> I see the point (when lookign from a maintenance perspective) but if
> genkernel 4.x has the power to work with different kernel versions, at
> least the kernel to operate with must be passed to the initramfs
> generator, right?

Yes, kernel version must be passed to initramfs generator, but that's
all.


> I could imagine it would even make sense to implement and forward all
> the options initially.

What options?  What do you mean?


> > After successful reboot the cleanup could be made either by user
> > command or automatically with some startup script.  Following items
> > could be removed:
> >
> > 1. old trees in /lib/modules
> > 2. old config, System.map and vmlinuz files from /boot
> > 3. old initramfs image from /boot
> > 4. old entries from boot manager
> > 5. clean/mrproper old sources
> > 6. (optionally) old sources if not managed by portage
>
> Existing tool app-admin/eclean-kernel comes to my mind.  We should
> check where re-use or duplication makes sense.

Ok, I'll take it into account.


-- 
Amadeusz Żołnowski