1 |
Hi Amadeusz, |
2 |
|
3 |
|
4 |
On 09/10/2012 08:27 AM, Amadeusz Żołnowski wrote: |
5 |
>> I am wondering (and asking) because we cannot make a genkernel |
6 |
>> 5.x with just a small fraction of what genkernel 3.4.x already |
7 |
>> could do. |
8 |
> |
9 |
> Yes, I am going to include all these feature plus extras, but I |
10 |
> might redesign options handling, for example instead of |
11 |
> --[no-]menuconfig, --[no-]gconfig I'd better use |
12 |
> --configdialog=[menuconfig|gconfig]. It should not be a problem, |
13 |
> since a major release is being bumped and initramfs handling is |
14 |
> going to be different anyway. |
15 |
|
16 |
I see. How is the implementation going to be quick then? How many |
17 |
months are we speaking? All these features need implementation and |
18 |
(more or less extensive) testing. |
19 |
|
20 |
|
21 |
> This is not a problem, because initramfs generator is just being |
22 |
> called without any manipulation - all options for initramfs |
23 |
> generator would be passed as is. It would be best if user would |
24 |
> configure Geninitramfs in /etc/geninitramfs.conf and Dracut in |
25 |
> /etc/dracut.conf.d/99user.conf and these default config files would |
26 |
> be used unless specified differently. Options could be provided by |
27 |
> user also in command line, for example: |
28 |
> |
29 |
> genkernel [kerneloptions] -- [initramfsoptions] |
30 |
|
31 |
That's a neat idea. Still my concern was (and is) a different one. |
32 |
To give an example, in the case where the resulting initramfs is going |
33 |
to be integrated into the kernel image, the destination of the |
34 |
initramfs generator must be known to genkernel 5.x (if it cannot be |
35 |
specified). For that feature, genkernel 5.x needs to handle dracut |
36 |
and genkernel differently. I am basically trying to say that it makes |
37 |
a more healthy development process to develop both in parallel rather |
38 |
than one backend after the other. |
39 |
|
40 |
|
41 |
>> Come on, are you seriously suggesting Bash for real software in |
42 |
>> 2012? There are no proper dictionaries in Bash, lists and |
43 |
>> seperators are a pain. Bash is a shell, good for ebuilds and |
44 |
>> scripts, and bad for real software. |
45 |
> |
46 |
> I am suggesting appropiate tool for this task. Please explain me |
47 |
> with real arguments how Python would be better than Bash4. I have |
48 |
> mentioned altering boot manager configuration and parsing |
49 |
> kernel.org already, but that still doesn't promote Python for the |
50 |
> whole Genkernel. |
51 |
|
52 |
I have given the real arguments already; there are honestly no hidden |
53 |
real ones. I use Bash and Python at work daily, so I know what Bash |
54 |
is good at and what it isn't. Let's take argument parsing as an |
55 |
example actually again), since you don't get around that one. How are |
56 |
you going to do that in Bash, cleanly? Using getopt(1)? Using a big |
57 |
case statement with extracting "foo" from "--param=foo"? In current |
58 |
genkernel that's a mess because it is Bash and not Python. And I do |
59 |
like Bash btw, just not for the next genkernel. I don't know what |
60 |
else to say. |
61 |
|
62 |
Best, |
63 |
|
64 |
|
65 |
|
66 |
Sebastian |