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
signature.asc
Description: This is a digitally signed message part
