1 |
Quoting Sebastian Pipping (2012-09-09 19:21:23) |
2 |
> On 09/09/2012 02:46 PM, Amadeusz Żołnowski wrote: |
3 |
> > Geninitramfs is going to be extracted not earlier than Genkernel4 is |
4 |
> > usable with Dracut to avoid synchronization work between |
5 |
> > Geninitramfs and Genkernel3. |
6 |
> |
7 |
> I don't get that point, to be honest. What is the problem and how |
8 |
> does pushing the spliut further way help about it? |
9 |
|
10 |
It helps that you don't care about Genkernel4 and Geninitramfs yet until |
11 |
Genkernel4 is ready for users. |
12 |
|
13 |
1) I implement Genkernel4 working with Dracut (might take some time) |
14 |
2) Genkernel4 is ready for use |
15 |
|
16 |
Until now Genkernel3 development is not interfered. |
17 |
|
18 |
3) Genkernel3 development is frozen (only bug fixes) |
19 |
4) Genkernel3 is moved, as I have described earlier, to Geninitramfs |
20 |
(this is going to be quick) |
21 |
5) I make Genkernel4 support Geninitramfs (this is going to be quick) |
22 |
|
23 |
There's no need for any wrapper. |
24 |
|
25 |
|
26 |
> One thing missing in the migration: does geninitramfs keep using |
27 |
> /etc/genkernel.conf ? If so, how do we handle that? if not, how do |
28 |
> we migrate smoothly? |
29 |
|
30 |
No, geninitramfs would use /etc/geninitramfs.conf, of course. |
31 |
|
32 |
|
33 |
> > Genkernel4 is going to be rewritten from scratch in Bash4 and |
34 |
> > possibly with some help of Python if necessary. |
35 |
> |
36 |
> Unlike with init scripts, there is no need for using shell scripting |
37 |
> here, right? If so, let's stick to Python >=2.6 only, if just for |
38 |
> argparse alone. Bash is one of genkernel's current issues in my |
39 |
> opinion. |
40 |
|
41 |
What Genkernel does is mostly calling shell commands. Bash4 is the best |
42 |
tool for this task if used correctly. I'd use Python for helper tools |
43 |
only if implementing something in Bash4 is PITA. |
44 |
|
45 |
|
46 |
> > 02. Select version |
47 |
> > |
48 |
> > a) local |
49 |
> > |
50 |
> > User selects one of versions listed with "list -l" with arguments |
51 |
> > "select -l <version>/<position of version on the list>". The check |
52 |
> > if sources still exist is done and the choice is remembered. |
53 |
> > |
54 |
> > b) remote |
55 |
> > |
56 |
> > User selects one of versions listed with "list -r" which doesn't |
57 |
> > exist in /usr/src with arguments "select -r <version>/<position of |
58 |
> > version on the list>". It is checked if this particular version |
59 |
> > could be downloaded and the choice is remembered. |
60 |
> |
61 |
> These are feature additions, if I am not mistaken. Sounds good for |
62 |
> later. |
63 |
|
64 |
Do you mean the remote stuff? Yes, possibly I'll implement that later. |
65 |
And this is where Python might become handy. |
66 |
|
67 |
|
68 |
> > 07. Build kernel and modules |
69 |
> > |
70 |
> > Runs "make" with CFLAGS, LDFLAGS, and JOBS given by user (in config |
71 |
> > file). |
72 |
> |
73 |
> The question of building as root or non-root by our own Tobias |
74 |
> Klausmann pops into my mind: |
75 |
> <http://blog.i-no.de//archives/2012/07/index.html#e2012-07-04T19_28_32.txt> |
76 |
|
77 |
Thanks. I'll take that into account. |
78 |
|
79 |
|
80 |
> > 10. Build initramfs |
81 |
> > |
82 |
> > An initramfs is going to be build either by Dracut or by |
83 |
> > Geninitramfs. I'd like to avoid using command line options of |
84 |
> > Genkernel to pass to Geninitramfs or Dracut therefore Geninitramfs |
85 |
> > or Dracut config is going to be used only. |
86 |
> |
87 |
> I see the point (when lookign from a maintenance perspective) but if |
88 |
> genkernel 4.x has the power to work with different kernel versions, at |
89 |
> least the kernel to operate with must be passed to the initramfs |
90 |
> generator, right? |
91 |
|
92 |
Yes, kernel version must be passed to initramfs generator, but that's |
93 |
all. |
94 |
|
95 |
|
96 |
> I could imagine it would even make sense to implement and forward all |
97 |
> the options initially. |
98 |
|
99 |
What options? What do you mean? |
100 |
|
101 |
|
102 |
> > After successful reboot the cleanup could be made either by user |
103 |
> > command or automatically with some startup script. Following items |
104 |
> > could be removed: |
105 |
> > |
106 |
> > 1. old trees in /lib/modules |
107 |
> > 2. old config, System.map and vmlinuz files from /boot |
108 |
> > 3. old initramfs image from /boot |
109 |
> > 4. old entries from boot manager |
110 |
> > 5. clean/mrproper old sources |
111 |
> > 6. (optionally) old sources if not managed by portage |
112 |
> |
113 |
> Existing tool app-admin/eclean-kernel comes to my mind. We should |
114 |
> check where re-use or duplication makes sense. |
115 |
|
116 |
Ok, I'll take it into account. |
117 |
|
118 |
|
119 |
-- |
120 |
Amadeusz Żołnowski |