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

[Sebastian Pipping]

Hi Amadeusz,


On 09/10/2012 08:27 AM, Amadeusz Żołnowski wrote:
>> 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.

I see.  How is the implementation going to be quick then?  How many
months are we speaking?  All these features need implementation and
(more or less extensive) testing.


> 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]

That's a neat idea.  Still my concern was (and is) a different one.
To give an example, in the case where the resulting initramfs is going
to be integrated into the kernel image, the destination of the
initramfs generator must be known to genkernel 5.x (if it cannot be
specified).  For that feature, genkernel 5.x needs to handle dracut
and genkernel differently.  I am basically trying to say that it makes
a more healthy development process to develop both in parallel rather
than one backend after the other.


>> 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.

I have given the real arguments already; there are honestly no hidden
real ones.  I use Bash and Python at work daily, so I know what Bash
is good at and what it isn't.  Let's take argument parsing as an
example actually again), since you don't get around that one.  How are
you going to do that in Bash, cleanly?  Using getopt(1)?  Using a big
case statement with extracting "foo" from "--param=foo"?  In current
genkernel that's a mess because it is Bash and not Python.  And I do
like Bash btw, just not for the next genkernel.  I don't know what
else to say.

Best,



Sebastian