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
- 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
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
- 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
- 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:
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
is performed. Benefits are that extra functionality can be added
(customizing the live environment for instance) without having to touch
I'll be sending more stuff when the documentation for building livecds
more remarks below
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
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.
> I will work on getting the sparc64 example livecd scripts
> fully updated by tomorrow. These changes should definitely be "worth
> in the long-run.
email@example.com mailing list