On Sat, 2008-04-19 at 11:19 +0800, Max Arnold wrote:
> On Fri, Apr 18, 2008 at 03:12:08PM -0700, Chris Gianelloni wrote:
> > > My steps are: stage3-i686-2007.0 + recent snapshot -> stage1 -> stage2 -> stage3 -> stage4
> >
> > OK, start from an x86 stage3, though.
>
> Is it critical? I'm shipping only stage4 and it will be deployed on fixed
> hardware configuration.
If you're building a stage1, you should always use a generic stage3 as
your seed. It likely isn't critical for you, but it's good practice to
get used to doing.
> > > So it is seems that my stage4/use and portage_confdir does not affect system packages
> > > (I guess that catalyst does only --emptytree when emerging stage4).
> >
> > Ehh, not quite. The USE you set in your spec only affects the stage
> > build. It doesn't affect what happens *after* the stage build. It also
> > doesn't affect packages built before your current stage build. One
> > thing that you did not mention is what version of catalyst that you're
> > using. Newer versions of catalyst, like the currently masked
> > 2.0.6_pre17, support writing out spec_prefix/use to make.conf so the
> > changes "stick" in your stage.
>
> I'm using catalyst-2.0.5, but at least on stage4 it puts my stage4/use into make.conf
> and copies content of portage_confdir to /etc/portage. I've just verified it in
> resulting stage4 tarball.
Sure, but none of your earlier stages did this correctly and even the
stage4 target doesn't get it quite right. Upgrade your catalyst
version.
> > > So, there are my questions:
> > >
> > > 1. Am I correct in assumption that use flags are stacked during stage4 like this:
> > > profile -> stage4/use -> package.use (increasing priority from left to right)?
> >
> > That's over-simplified, but yes.
>
> The reason I'm asking this is a phrase "If you set the portage configuration dir: package.use
> doesn't work how you think it should in catalyst. It's a known bug, but one that won't
> likely be fixed for some time. Basically, if you use $target/use, then it will ignore
> package.use settings." here: http://gentoo-wiki.com/HOWTO_build_a_LiveCD
> Is that already fixed?
It should be *only* in newer catalyst, not the current stable.
> > > 2. What is the proper (and simple to maintain) way to deviate slightly in system use flags?
> >
> > The way that you're doing it works fine if you're planning on shipping a
> > stage4 all the time. Were I doing this myself, I'd make a new profile
> > with the desired changes, but that's just me.
> >
> > > My guesses:
> > > 1. Add 'hostuse' variable to earlier specs (stage3?)
> >
> > Already done in newer catalyst versions...
>
> 2.0.5 uses it: generic_stage_target.py adds hostuse to valid_values list, and
> stage4_chroot.sh mentions $clst_HOSTUSE. But is it safe to simply define hostuse
> in stage spec? Is it additive (I see x86.py assigns some values to this variable) or
> arch specific value will be simply overridden and it is better to do not redefine it?
You cannot redefine it. It is defined exactly once. HOSTUSE is
literally *only* for subarchitecture-specific USE which controls CPU
capabilities/features. It is only designed to be used internally, so if
you try to do anything with it, I cannot guarantee what will happen.
> > > 4. Create my own profile (don't know where to put it and how to maintain during tree updates)
> >
> > This is what you should do. Simply stick it in $portdir/profiles where
> > you'd like it before running your snapshot. To keep "emerge --sync"
> > from wiping it out, add
> > PORTAGE_RSYNC_EXTRA_OPTS="--exclude=profiles/myprofilename" to
> > your /etc/make.conf on your host/build system.
>
> Can be custom profile added to portage_overlay on all stages istead of putting it to tree?
Yes, it can, but it is safer to put it into your tree that you're using
for your snapshots. I suggest keeping a separate portage tree from
"/usr/portage" for this, so you don't have to worry about accidentally
hosing it.
> BTW, what is the difference between profiles/default/linux and profiles/default-linux ?
Well, profiles/default/linux is the new location and default-linux will
be going away, so that makes it rather simple. ;]
> So for now I'll try to upgrade catalyst, add portage_confdir to all stages, leave only
> stage4/use (for additional world packages) and experiment with profiles.
Sounds great!
> I also have some more general questions, but I'll ask them in another thread.
OK.
> Thank you!
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
|
