I'm deliberately starting a new thread here, because this is meandering well off the original topic of the global useflag proposals.
On Thu, Oct 16, 2008 at 02:18:16AM +0200, Marius Mauch wrote: > There are also other issues, e.g. it breaks the generation of the > @installed package set as the installed slots can't be found in the > tree. As portage-2.2 makes increased use of slot atoms internally for > vdb handling we got a few bugreports simply due to the cache constraint > violation by USE=multislot. Ok, I found bug #174184 on this matter. kugelfang proposed to include this in EAPI=1, but I don't find it in there, what happened? The short-term fix of use.mask just stops current breakage, but we need a real solution so that we can keep using it where we actually need it. Ignoring Vapier's tirade against ciaranm there, we need the xDEPEND-syntax for SLOTS as the real solution, however that still wouldn't resolve the portion that has CTARGET as part of the SLOT, since metadata generated on the rsyncmaster with a different CTARGET wouldn't match on the clients. I'm also wondering about a bad interaction with slot dependencies even without having CTARGET: Say gcc has two variants, SLOT=3.4 and SLOT=3.4.5. The language in the approved version of PMS (section 9.2.5) states: "A specification with a named slot dependency matches only if the slot of the matched package is squal to ths lot specified." So if package foo/bar-1.0 contains DEPEND="sys-devel/gcc:3.4" it wouldn't match the other variant of gcc with SLOT=3.4.5 :-(. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpAf5eX3m8Sz.pgp
Description: PGP signature
