On Tue, Aug 08, 2006 at 09:23:34PM +0200, Thomas de Grenier de Latour wrote: > On Tue, 8 Aug 2006 00:22:50 -0700, > Brian Harring <[EMAIL PROTECTED]> wrote: > > > forcing cxx on via package.mask for gcc > > sys-devel/gcc[-cxx] > > If i want to build a cxx-free system, am i supposed to add > "sys-devel/gcc[-cxx]" to its package.unmask? If so, what will prevent > Portage upgrading to some package.masked 4.2_alpha version? After all, > that's what a depatom interpretation would imply. > > Or am i supposed to carefully unmask "=sys-devel/gcc-4.1*[-cxx]" only, > and pray for not overlooking the 4.2 upgrade when it comes (since it > would bring cxx back in), and that there won't ever be a gcc-4.1.99-r42 > dev's playground?
Sarcasm aside, day or so I've sat and wondered about this one I don't have a good answer. For others who missed it, masks are collapsed into one statement, unmasks are collapsed into another, visibility is determined via if (!MASKED || UNMASKED) essentially. Sliding per package use masking into a seperate file sidesteps the issue via allowing for easier implementation- if (!USE_MASKED || USE_UNMASKED) && (!MASKED || UNMASKED) That said, it still is an issue when use-deps hit- there isn't anything blocking a use dep being slid into the masks, requiring version ranges to be used to nuke it sanely via unmask. General problem with use deps; *could* still implement it via seperating out use specific restrictions and generating the second logic statement above, but that's bit magic imo. Perhaps an alt op? > Or am i supposed to put "-sys-devel/gcc[-cxx]" in > some profile overriding file? But then, when the tree mask is changed > to "sys-devel/gcc[-cxx,-fortran]", my diff rule will suddenly be lost > (this method of text lines overriding is okay in the context of > official profiles, where coherent changesets can be done at once, but > in user's config files, it's hell to maintain). Affect would be cumulative in that case, you'd wind up with a masking of sys-devel/gcc[-fortran] > In short, i hope that either i have missed something about your > proposal, No, per the norm you spotted something annoying overlooked by everyone else who commented. :/ Suggestions welcome- it can be sidestepped via seperate file, down the line when use-deps are available, the potential will still be waiting. Definitely grounds to force package.* instead of reusing unmask/mask, but I'd still like to get some form of solution for the general issue here- it's not going to go away unfortunately. ~harring
pgpwfDifkbvRU.pgp
Description: PGP signature
