1 |
On Tue, Aug 08, 2006 at 09:23:34PM +0200, Thomas de Grenier de Latour wrote: |
2 |
> On Tue, 8 Aug 2006 00:22:50 -0700, |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > forcing cxx on via package.mask for gcc |
6 |
> > sys-devel/gcc[-cxx] |
7 |
> |
8 |
> If i want to build a cxx-free system, am i supposed to add |
9 |
> "sys-devel/gcc[-cxx]" to its package.unmask? If so, what will prevent |
10 |
> Portage upgrading to some package.masked 4.2_alpha version? After all, |
11 |
> that's what a depatom interpretation would imply. |
12 |
> |
13 |
> Or am i supposed to carefully unmask "=sys-devel/gcc-4.1*[-cxx]" only, |
14 |
> and pray for not overlooking the 4.2 upgrade when it comes (since it |
15 |
> would bring cxx back in), and that there won't ever be a gcc-4.1.99-r42 |
16 |
> dev's playground? |
17 |
|
18 |
Sarcasm aside, day or so I've sat and wondered about this one I don't |
19 |
have a good answer. |
20 |
|
21 |
For others who missed it, masks are collapsed into one statement, |
22 |
unmasks are collapsed into another, visibility is determined via |
23 |
if (!MASKED || UNMASKED) essentially. |
24 |
|
25 |
Sliding per package use masking into a seperate file sidesteps the |
26 |
issue via allowing for easier implementation- |
27 |
if (!USE_MASKED || USE_UNMASKED) && (!MASKED || UNMASKED) |
28 |
|
29 |
That said, it still is an issue when use-deps hit- there isn't |
30 |
anything blocking a use dep being slid into the masks, requiring |
31 |
version ranges to be used to nuke it sanely via unmask. |
32 |
|
33 |
General problem with use deps; *could* still implement it via |
34 |
seperating out use specific restrictions and generating the second |
35 |
logic statement above, but that's bit magic imo. |
36 |
|
37 |
Perhaps an alt op? |
38 |
|
39 |
> Or am i supposed to put "-sys-devel/gcc[-cxx]" in |
40 |
> some profile overriding file? But then, when the tree mask is changed |
41 |
> to "sys-devel/gcc[-cxx,-fortran]", my diff rule will suddenly be lost |
42 |
> (this method of text lines overriding is okay in the context of |
43 |
> official profiles, where coherent changesets can be done at once, but |
44 |
> in user's config files, it's hell to maintain). |
45 |
|
46 |
Affect would be cumulative in that case, you'd wind up with a masking |
47 |
of sys-devel/gcc[-fortran] |
48 |
|
49 |
|
50 |
> In short, i hope that either i have missed something about your |
51 |
> proposal, |
52 |
|
53 |
No, per the norm you spotted something annoying overlooked by everyone |
54 |
else who commented. :/ |
55 |
|
56 |
Suggestions welcome- it can be sidestepped via seperate file, down |
57 |
the line when use-deps are available, the potential will still be |
58 |
waiting. |
59 |
|
60 |
Definitely grounds to force package.* instead of reusing unmask/mask, |
61 |
but I'd still like to get some form of solution for the general issue |
62 |
here- it's not going to go away unfortunately. |
63 |
|
64 |
~harring |