When using catalyst 1.0.9 in an ~x86 environment (set in catalyst-env.sh), virtuals seem not to work in the livecd-stage1 stage. This is what I do: Make a livecd spec file, using default-linux/x86/2004.2/gcc34/2.6 profile. I got alsa in my use flags, and alsa-utils in my package list. Gentoo-dev-sources is emerged inside the chroot when running catalyst (2.6.8-r9 here if I'm not mistaken). Looking at the kernel-2 eclass, this should provide the virtual/alsa virtual. This is not what really happens: when starting to emerge the deps of alsa-utils, alsa-drivers wants to be emerged (which is the default alsa virtual in the profile), which fails on a 2.6 kernel. I dont know wether this is a catalyst or a portage bug. It is possible to fix this (altough it's an ugly hack): Portage 2.0.51 provides the possibility to pu user defined virtuals in /etc/portage/profile/virtuals, so if I put this in catalyst-env.sh: mkdir -p /etc/portage/profile && echo "virtual/alsa sys-kernel/gentoo-dev-sources" >> /etc/portage/profile/virtuals alsa-drivers isnt merged as a dep of alsa-utils, and everything works fine. I did not tyu this on other virtuals, but I expect the result to be the same.
It isn't just ~x86... Catalyst in livecd-stage2 will *always* merge the default for the virtual, even if another package which satisfies the virtual.
...err... I meant livecd-stage1... and yeah... it's annoying... this same thing bit me on the gamecd stuff I've been working on recently.
zhen: Remember when I asked you if we could have livecd-stage1 perform one massive emerge for all of the packages supplied? Well, for some reason, portage/catalyst doesn't like doing this properly. Anyway, I have commited a fix to CVS to actually perform each package emerge separately and guess what? This problem went away. It also really makes dependencies easier to track down when a package (like X) is being pulled in when you don't want it, as you can see where it gets pulled into the build.
is it a bug with portage? if so, let's get the portage folk to fix it. I really do not like having all of the packages merged indpendently as each time portage has to be reloaded, deps recalculated, etc, and that takes *time* let's try to get the portage people in on this..
portage-2.0.51 should mostly fix this.. There was one more bug regarding virtuals but is fixed in >portage-2.0.51-r3. Can you confirm if the problem still exists with one of those (currently ~arch) versions?
Hrrrmn... I was still using -r3. I'll check it out with a newer portage and see what it does.
any news on this Chris?
I'm checking this out now... so I'll let you know how it goes... initial run didn't look good... so I am trying again and actually watching it this time around to see how it goes.
I added a bit of code to catalyst to use portageq to determine the version of portage installed. If the portage versions is >=2.0.51-r4, then it runs a single emerge, otherwise, it runs each emerge separately. While this is not the optimal solution, it will cause virtuals to act correct no matter what version of portage is used.
Catalyst 1.1.2 is now out!
