Re: [gentoo-catalyst] Keeping a test environment using catalyst

[Chris Gianelloni]

On Wed, 2005-05-11 at 12:39 -0400, Paul Smith wrote:
> %% Chris Gianelloni <wolf31o2@g.o> writes:
>
>   cg> We don't do any shortcuts simply because we *are* the catalyst
>   cg> developers.  When we find shortcomings in catalyst, we fix them.  ;]
>
>   >> If there are no fancy tricks that I'm missing I'm sure I can come up
>   >> with some myself :-).
>
>   cg> Like I said before, I'm not sure I really follow what you're
>   cg> trying to do.
>
> Hi Chris; thanks for taking the time to reply!
>
> I completely see your viewpoint here.  My situation is that I'm trying
> to add somewhat more esoteric software to my livecd than comes on a
> "typical" livecd.  Some of it doesn't even have any Gentoo ebuilds, so
> I'm writing them myself.  For ebuilds that are in Gentoo, I need to run
> emerge -p to see what would be pulled in, investigate the USE flags in
> the ebuilds to see if I can turn off features I don't like, then see
> what would be pulled in, etc.  Also, to find out what I can unmerge and
> still have the thing work properly.

OK.  This makes sense to me now.

> In a situation like this it's very time consuming to have to rebuild
> livecd1 and then livecd2 every time I need to tweak an ebuild or add or
> remove a package, so I was looking for a "development mode" where things
> were maybe not as clean, but were "good enough" to allow development
> work to proceed quickly.  Then obviously there's polishing at the end
> that would have to be done more cleanly.

Your best bet here is then to chroot into your livecd-stage1 and start
playing.  Remember that catalyst just uses "emerge" for most of its
work, so you can easily duplicate the steps.

You might also want to look into the tinderbox target.  It will allow
you to determine just what is required above and beyond a stage3 tarball
to get your packages working.

Personally, I prefer the USE="-*" approach, rather than deciding what
you don't need, try to figure out what you want.  Turn everything off,
then only turn on what you really need.

> I quite understand your position: you are using ostensibly stable Gentoo
> packages and your work is focused on making sure Catalyst works.  I'm
> using unstable/development packages and assuming that Catalyst is stable.

Catalyst is anything but stable.  It works quite well for building a
*Gentoo* release, but is not well suited for other things (yet) simply
due to that being the only focus of catalyst until recently.

> Anyway, I think I have enough now to work with for the moment; adding in
> libstdc++ works (I did this last night but forgot to send email), and I
> can bind-mount the snapshot and chroot and that works as well.

Cool.

> My current project is understanding where the kernel boot parameters
> come from (my bootline has "nodhcp" which I don't want).  My other
> problem is that the hardware detection stuff is running too late in the
> "default" boot process; it brings up eth0, then sshd, then apache,
> _THEN_ runs the hardware detection.  So, I can't quite figure out how it
> brings up eth0 without detecting the hardware... maybe it runs twice?

All of the boot parameters come from the archscript.  Normally,
autoconfig is started first due to it being first alphabetically.  The
"hwsetup" portion you see on the Gentoo releases is done by autoconfig,
and runs before coldplug.

Just curious, but what arch are you building?  x86?  amd64?  ppc?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux