1 |
Hey, |
2 |
|
3 |
I tried building ppc livecds with catalyst and genkernel yesterday. I |
4 |
have some remarks. |
5 |
|
6 |
|
7 |
- PRE requirements need to be checked before starting work on something: |
8 |
If there is no snapshot, stage3 shouldn't be unpacked only to be |
9 |
removed because the snapshot can't be found. A simple typo in the date |
10 |
for the snapshot can lead to a half our of unpacking and removing |
11 |
stage3's. |
12 |
|
13 |
- if PRE requirements are satisfied, there is no need to throw earlier |
14 |
work away and start all over again: |
15 |
E.g: a huge number of packages needs to be merged in the stage3, if one |
16 |
of those packages is masked on your architecture, it is frustrating to |
17 |
have to wait until stage3 is unpacked, snapshot gets unpacked,... only |
18 |
to see |
19 |
another package is also masked and have to restart all over again. The |
20 |
ppc scripts used to touch files when certain milestones are reached, on |
21 |
relaunch of the program the fine-grained stages (!= current catalyst |
22 |
stages) corresponding to the touched files are skipped. |
23 |
|
24 |
- HD space requirements: Because a tarball is created on every catalyst |
25 |
stage, space requirements are huge. I estimate that building a |
26 |
kde/gnome cd with a 2G live environment must take about 10G to build |
27 |
when compressed with gcloop. In my case unpacking the snapshot looped |
28 |
infinitely because my hd was full. |
29 |
|
30 |
- difficult if not impossible to pass variables such as PROXY to the |
31 |
chroot. This is only a problem if non-GRP packages need to be built in |
32 |
the chrooted env. Please implement a common way to pass such variables |
33 |
and do not do this on a per case basis (distcc variables, proxy |
34 |
variables, ...) |
35 |
|
36 |
- alsa-driver, mac on linux, nvidia kernel, ati-drivers add stuff to |
37 |
the kernel / kernel modules. Is this still possible with genkernel? |
38 |
|
39 |
- Haven't tested this one but is it possible to perform a --pretend , |
40 |
showing the user what packages are going to be merged in the live |
41 |
environment before the packages are merged (and the hd runs out of |
42 |
space or the process takes forever because a nasty package requires X |
43 |
(which wasn't available as GRP))? |
44 |
|
45 |
- non-lethal: specs and config use different syntax. Wouldn't it be |
46 |
possible to use the same syntax we are used to (VARIABLE=""). The |
47 |
livecd/packages format also seems to differ from the format used for |
48 |
the portage profiles. |
49 |
|
50 |
- GRP_STAGE23_USE location seems weird. I'd expect this to be in |
51 |
catalyst.conf instead of make.default, because it is only used by |
52 |
catalyst. |
53 |
|
54 |
- Are the livecd stages required? Gentoo/PPC developer livecds are |
55 |
basic livecds without stuff cleaned. I'd expect the cleaning process to |
56 |
be triggerable in a spec file. Why can't the installation of a kernel |
57 |
be also such a triggerable thing? This removes the need for iterated |
58 |
'tarball creation, tarball unpack, tarball creation'. Also, I'd like to |
59 |
suggest the technique used for the ppc livecd script: |
60 |
|
61 |
One huge file with a switch statement may break if one of the |
62 |
conditions is broken. A proper design would be to create a separate, |
63 |
correctly named file for each functionality: |
64 |
|
65 |
kernel |
66 |
install |
67 |
remove |
68 |
|
69 |
In your spec file you just say: |
70 |
|
71 |
todo: kernel , install, remove |
72 |
|
73 |
In the ppc scripts the files with the functionality are copied in the |
74 |
live environment before chroot, and |
75 |
|
76 |
chroot /livecd/kernel |
77 |
chroot /livecd/install |
78 |
chroot /livecd/remove |
79 |
|
80 |
is performed. Benefits are that extra functionality can be added |
81 |
(customizing the live environment for instance) without having to touch |
82 |
other things. |
83 |
|
84 |
I'll be sending more stuff when the documentation for building livecds |
85 |
is available. |
86 |
|
87 |
more remarks below |
88 |
|
89 |
Pieter |
90 |
|
91 |
On 21 Jan 2004, at 07:02, Daniel Robbins wrote: |
92 |
|
93 |
> Just unmask baselayout-r4, gentoo-dev-sources-2.6.1-r1 |
94 |
> and the latest genkernel in your snapshot and everything should work |
95 |
> fine. |
96 |
|
97 |
Is a 2.6 kernel a requirement for catalyst livecd building? |
98 |
|
99 |
> the various parts of the runscript/archscript have been renamed, and |
100 |
> some parts have been combined and/or deprecated. We now have the |
101 |
> following, which run in the order specified: |
102 |
> |
103 |
> preclean - prep livecd environment, do a bit of cleaning |
104 |
> kernel - build kernel |
105 |
> bootloader - configure bootloader |
106 |
> clean - clean up with chroots unmounted |
107 |
> cdfs - prepare cd filesystem (loopback, zisofs, etc.) |
108 |
|
109 |
see remark above. Promoting reuse is important. |
110 |
|
111 |
> I should have docs and a quick tutorial online sometime tomorrow. To |
112 |
> Weeve and others who have started work on LiveCD stuff: sorry for these |
113 |
> late changes. |
114 |
|
115 |
np. |
116 |
|
117 |
> I will work on getting the sparc64 example livecd scripts |
118 |
> fully updated by tomorrow. These changes should definitely be "worth |
119 |
> it" |
120 |
> in the long-run. |
121 |
|
122 |
indeed |
123 |
|
124 |
> Regards, |
125 |
> |
126 |
> Daniel |
127 |
|
128 |
|
129 |
-- |
130 |
gentoo-releng@g.o mailing list |