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

Attachment: pgpwfDifkbvRU.pgp
Description: PGP signature

Reply via email to