| 1 |
On Fri, 2008-04-18 at 11:29 +0800, Max Arnold wrote: |
| 2 |
> I'm trying to build my own stage4 with specific packages and use flags. |
| 3 |
> My steps are: stage3-i686-2007.0 + recent snapshot -> stage1 -> stage2 -> stage3 -> stage4 |
| 4 |
|
| 5 |
OK, start from an x86 stage3, though. |
| 6 |
|
| 7 |
> Specs for stages 1-3 are generic (just copied from releng/specs/2007.0/x86), and stage4 |
| 8 |
> adds portage_confdir, stage4/use and several packages. |
| 9 |
> |
| 10 |
> Stage4 compiles fine, but when I chroot to it and issue emerge -pvuDN world, portage |
| 11 |
> wants to remerge several system packages due to changed use flags (for example ipv6, which |
| 12 |
> is disabled in my stage4/use). |
| 13 |
> |
| 14 |
> So it is seems that my stage4/use and portage_confdir does not affect system packages |
| 15 |
> (I guess that catalyst does only --emptytree when emerging stage4). |
| 16 |
|
| 17 |
Ehh, not quite. The USE you set in your spec only affects the stage |
| 18 |
build. It doesn't affect what happens *after* the stage build. It also |
| 19 |
doesn't affect packages built before your current stage build. One |
| 20 |
thing that you did not mention is what version of catalyst that you're |
| 21 |
using. Newer versions of catalyst, like the currently masked |
| 22 |
2.0.6_pre17, support writing out spec_prefix/use to make.conf so the |
| 23 |
changes "stick" in your stage. |
| 24 |
|
| 25 |
> So, there are my questions: |
| 26 |
> |
| 27 |
> 1. Am I correct in assumption that use flags are stacked during stage4 like this: |
| 28 |
> profile -> stage4/use -> package.use (increasing priority from left to right)? |
| 29 |
|
| 30 |
That's over-simplified, but yes. |
| 31 |
|
| 32 |
> 2. What is the proper (and simple to maintain) way to deviate slightly in system use flags? |
| 33 |
|
| 34 |
The way that you're doing it works fine if you're planning on shipping a |
| 35 |
stage4 all the time. Were I doing this myself, I'd make a new profile |
| 36 |
with the desired changes, but that's just me. |
| 37 |
|
| 38 |
> My guesses: |
| 39 |
> 1. Add 'hostuse' variable to earlier specs (stage3?) |
| 40 |
|
| 41 |
Already done in newer catalyst versions... |
| 42 |
|
| 43 |
> 2. Add 'portage_confdir' to earlier specs (but my -ipv6 listed in stage4/use and not in package.use) |
| 44 |
|
| 45 |
You should always use the same portage_confdir across all stages. In |
| 46 |
the future, catalyst will check for this and will refuse to run if you |
| 47 |
didn't use the same snapshot and portage_confdir on your stages. This |
| 48 |
should hopefully reduce the number of "human errors" made when people |
| 49 |
are using catalyst. ;] |
| 50 |
|
| 51 |
> 3. Create new target (based on stage4 code) and add --newuse somewhere |
| 52 |
|
| 53 |
It wouldn't matter. You'd need --newuse --deep. We specifically have |
| 54 |
not done this, as the stage4 code shares most of its code with the |
| 55 |
livecd/stage1 and livecd-stage2 code, which was originally written with |
| 56 |
the Minimal/Universal InstallCD in mind and doesn't require rebuilding |
| 57 |
the system packages to match the CD's USE. |
| 58 |
|
| 59 |
The best and most correct solution is to make your USE changes in a |
| 60 |
profile and use that profile to build your stages. |
| 61 |
|
| 62 |
> 4. Create my own profile (don't know where to put it and how to maintain during tree updates) |
| 63 |
|
| 64 |
This is what you should do. Simply stick it in $portdir/profiles where |
| 65 |
you'd like it before running your snapshot. To keep "emerge --sync" |
| 66 |
from wiping it out, add |
| 67 |
PORTAGE_RSYNC_EXTRA_OPTS="--exclude=profiles/myprofilename" to |
| 68 |
your /etc/make.conf on your host/build system. |
| 69 |
|
| 70 |
-- |
| 71 |
Chris Gianelloni |
| 72 |
Release Engineering Strategic Lead |
| 73 |
Games Developer |
| 74 |
-- |
| 75 |
gentoo-catalyst@l.g.o mailing list |
Archives