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

[Amadeusz Żołnowski]

Hello,

Quoting Sebastian Pipping (2012-09-10 01:08:06)
> let's be clear about your goals for genkernel 5.x.  Are you aiming at
> re-writing support for all of the current kernel options of genkernel
> below?
>
> I am wondering (and asking) because we cannot make a genkernel 5.x
> with just a small fraction of what genkernel 3.4.x already could do.

Yes, I am going to include all these feature plus extras, but I might
redesign options handling, for example instead of --[no-]menuconfig,
--[no-]gconfig I'd better use --configdialog=[menuconfig|gconfig].  It
should not be a problem, since a major release is being bumped and
initramfs handling is going to be different anyway.


> > My progress could be used with Dracut until it is fully usable and
> > then Geninitramfs support could added quickly.
> >
> > My goal is to write Genkernel4/5 quickly, simply and painlessly as
> > well as do the split of Genkernel and Geninitramfs.  Where exactly
> > in the plan above is a real problem?
>
> If something is meant to be used with two backends, it's risky to
> develop for one and adding the other later.  To save surprises, each
> feature should be made working for both backends plus you need a clear
> and complete overview of how operation, feature sets and interfaces
> differ among these two backends upfront.

This is not a problem, because initramfs generator is just being called
without any manipulation - all options for initramfs generator would be
passed as is.  It would be best if user would configure Geninitramfs in
/etc/geninitramfs.conf and Dracut in /etc/dracut.conf.d/99user.conf and
these default config files would be used unless specified differently.
Options could be provided by user also in command line, for example:

genkernel [kerneloptions] -- [initramfsoptions]


> > Where you have to cope with complicated string manipulation in
> > Genkernel?  And what number of lines has to do with it?
>
> Come on, are you seriously suggesting Bash for real software in 2012?
> There are no proper dictionaries in Bash, lists and seperators are a
> pain.  Bash is a shell, good for ebuilds and scripts, and bad for real
> software.

I am suggesting appropiate tool for this task.  Please explain me with
real arguments how Python would be better than Bash4.  I have mentioned
altering boot manager configuration and parsing kernel.org already, but
that still doesn't promote Python for the whole Genkernel.


-- 
Amadeusz Żołnowski