1 |
On Tue, 14 Aug 2012 23:02:04 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Tue, 14 Aug 2012 14:55:47 -0700 |
5 |
> Zac Medico <zmedico@g.o> wrote: |
6 |
> > It seems like there's some confusion here. Approving a new EAPI and |
7 |
> > deciding to use a new EAPI in a given profile are two entirely |
8 |
> > different things. If we want to us a new EAPI in a profile, we just |
9 |
> > have to deploy it such that users are only exposed to that profile |
10 |
> > when they consciously running `eselect profile` (and they can always |
11 |
> > revert back to the previous profile if it turns out that their |
12 |
> > installed package manager doesn't support the new profile). |
13 |
> |
14 |
> There's still the issue that we haven't decided what [use] deps do |
15 |
> when they show up in profile files. We were sticking at 1 until we |
16 |
> worked that out. |
17 |
|
18 |
Ah, about that. It will be useful if [use] deps in package.mask worked |
19 |
unlike in package.use.mask, thus giving us a tool to temporarily mask |
20 |
packages which are broken only with given flags. |
21 |
|
22 |
For example, likely it was potentially useful to do something like: |
23 |
|
24 |
# something support with intel broken in this version |
25 |
=media-libs/mesa-N.N.N[someflag,video_cards_intel,!video_cards_radeon,!video_cards_nvidia] |
26 |
|
27 |
With meaning: mask mesa-N.N.N if 'someflag' and 'video_cards_intel' are |
28 |
enabled, and 'video_cards_radeon' an 'video_cards_nvidia' are disabled. |
29 |
|
30 |
This will make lives easier both for devs (who wouldn't have to |
31 |
work-around this) and users (for those who will benefit from new mesa, |
32 |
and those who will not upgrade and break their systems). |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |