| 1 |
On Fri, 23 Mar 2018 11:53:40 +0100 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
|
| 4 |
> Still, masking is the wrong way to express such preferences. If you |
| 5 |
> package.mask sys-devel/gcc then you say that something is wrong with |
| 6 |
> that package. Which I believe is not what you want to express here. |
| 7 |
|
| 8 |
I might have a better usecase for adding masks from overlays. |
| 9 |
|
| 10 |
But its more for the usecase of "there isn't something wrong with that |
| 11 |
package", but the more frequent usecase of "Portage is stupid and so we |
| 12 |
have masks to coerce the right behaviour" |
| 13 |
|
| 14 |
For example, if I had an overlay that's sole purpose was to |
| 15 |
test/transition experimental versions of Perl, where the presumption |
| 16 |
was that by installing said overlay, that you wished to upgrade to that |
| 17 |
version of Perl, it might make sense to employ masks to prevent portage |
| 18 |
doing dumb things. |
| 19 |
|
| 20 |
And by "Dumb things", I mean some of the common problems I see where |
| 21 |
portage tries to solve a blocker by downgrading Perl.... |
| 22 |
|
| 23 |
Its much simpler to just author a blacklist of "Look, these are things |
| 24 |
that are known to be a mess, don't even consider installing them, with |
| 25 |
a nice description of why this is nonsense" |
| 26 |
|
| 27 |
Trying to achieve it by any other means simply tempts the problem to |
| 28 |
reappear in another form, because everything *other* than package.mask |
| 29 |
will have portage try to flip the USE flag to try to make it work, and |
| 30 |
end up with people needing --backtrack=1000 and having it still not |
| 31 |
work. |
| 32 |
|
| 33 |
package.mask is at least a "look, we know this is nonsense, don't even |
| 34 |
explore this line of reasoning" blunt instrument. |
Archives