Hey,

I tried building ppc livecds with catalyst and genkernel yesterday. I 
have some remarks.


- PRE requirements need to be checked before starting work on something:
If there is no snapshot, stage3 shouldn't be unpacked only to be 
removed because the snapshot can't be found. A simple typo in the date 
for the snapshot can lead to a half our of unpacking and removing 
stage3's.

- if PRE requirements are satisfied, there is no need to throw earlier 
work away and start all over again:
E.g: a huge number of packages needs to be merged in the stage3, if one 
of those packages is masked on your architecture, it is frustrating to 
have to wait until stage3 is unpacked, snapshot gets unpacked,... only 
to see
another package is also masked and have to restart all over again. The 
ppc scripts used to touch files when certain milestones are reached, on 
relaunch of the program the fine-grained stages (!= current catalyst 
stages) corresponding to the touched files are skipped.

- HD space requirements: Because a tarball is created on every catalyst 
stage, space requirements are huge. I estimate that building a 
kde/gnome cd with a 2G live environment must take about 10G to build 
when compressed with gcloop. In my case unpacking the snapshot looped 
infinitely because my hd was full.

- difficult if not impossible to pass variables such as PROXY to the 
chroot. This is only a problem if non-GRP packages need to be built in 
the chrooted env. Please implement a common way to pass such variables 
and do not do this on a per case basis (distcc variables, proxy 
variables, ...)

- alsa-driver, mac on linux, nvidia kernel, ati-drivers add stuff to 
the kernel / kernel modules. Is this still possible with genkernel?

- Haven't tested this one but is it possible to perform a --pretend , 
showing the user what packages are going to be merged in the live 
environment before the packages are merged (and the hd runs out of 
space or the process takes forever because a nasty package requires X 
(which wasn't available as GRP))?

- non-lethal: specs and config use different syntax. Wouldn't it be 
possible to use the same syntax we are used to (VARIABLE=""). The 
livecd/packages format also seems to differ from the format used for 
the portage profiles.

- GRP_STAGE23_USE location seems weird. I'd expect this to be in 
catalyst.conf instead of make.default, because it is only used by 
catalyst.

- Are the livecd stages required? Gentoo/PPC developer livecds are 
basic livecds without stuff cleaned. I'd expect the cleaning process to 
be triggerable in a spec file. Why can't the installation of a kernel 
be also such a triggerable thing? This removes the need for iterated 
'tarball creation, tarball unpack, tarball creation'. Also, I'd like to 
suggest the technique used for the ppc livecd script:

One huge file with a switch statement may break if one of the 
conditions is broken. A proper design would be to create a separate, 
correctly named file for each functionality:

kernel
install
remove

In your spec file you just say:

todo: kernel , install, remove

In the ppc scripts the files with the functionality are copied in the 
live environment before chroot, and

chroot /livecd/kernel
chroot /livecd/install
chroot /livecd/remove

is performed. Benefits are that extra functionality can be added 
(customizing the live environment for instance) without having to touch 
other things.

I'll be sending more stuff when the documentation for building livecds 
is available.

more remarks below

Pieter

On 21 Jan 2004, at 07:02, Daniel Robbins wrote:

> Just unmask baselayout-r4, gentoo-dev-sources-2.6.1-r1
> and the latest genkernel in your snapshot and everything should work
> fine.

Is a 2.6 kernel a requirement for catalyst livecd building?

> the various parts of the runscript/archscript have been renamed, and
> some parts have been combined and/or deprecated. We now have the
> following, which run in the order specified:
>
> preclean - prep livecd environment, do a bit of cleaning
> kernel - build kernel
> bootloader - configure bootloader
> clean - clean up with chroots unmounted
> cdfs - prepare cd filesystem (loopback, zisofs, etc.)

see remark above. Promoting reuse is important.

> I should have docs and a quick tutorial online sometime tomorrow. To
> Weeve and others who have started work on LiveCD stuff: sorry for these
> late changes.

np.

> I will work on getting the sparc64 example livecd scripts
> fully updated by tomorrow. These changes should definitely be "worth 
> it"
> in the long-run.

indeed

> Regards,
>
> Daniel


--
gentoo-releng@g.o mailing list