| 1 |
On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
>>>>>> On Fri, 23 Mar 2018, Roy Bamford wrote: |
| 3 |
> |
| 4 |
>> games-emulation/sdlmame is masked. I have a higher version in my |
| 5 |
>> overlay than the one in the tree and it gets masked too. |
| 6 |
>> Its not a problem to me as I know how to manage it. Its just untidy. |
| 7 |
> |
| 8 |
> You still don't need a repository specific mask for this. Version |
| 9 |
> specific masking and unmasking is entirely sufficient to express that |
| 10 |
> the higher version is fine. |
| 11 |
> |
| 12 |
|
| 13 |
I think it would be best to step back from terms like "masking" and |
| 14 |
focus more on the intended behavior. |
| 15 |
|
| 16 |
It sounds to me that one of the intended behaviors is to tell portage |
| 17 |
that for a particular package we want to ignore a particular |
| 18 |
repository entirely. Suppose for example an overlay contains |
| 19 |
misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want |
| 20 |
portage to stick with foo-3 from the overlay. However, if the overlay |
| 21 |
adds foo-4, or foo-4.1 we want this installed. A version mask would |
| 22 |
not really cover this use case. |
| 23 |
|
| 24 |
IMO this sounds like a useful feature. Having it in profiles could |
| 25 |
probably also be useful in some testing scenarios, such as when making |
| 26 |
changes to a large number of packages that are already in the main |
| 27 |
tree (think something analogous to a feature branch in git, where the |
| 28 |
master branch continues to advance). |
| 29 |
|
| 30 |
Perhaps I'm misunderstanding the intent here, but I would suggest that |
| 31 |
we describe the end goal in emails like these otherwise people focus |
| 32 |
on the implementation details first. |
| 33 |
|
| 34 |
-- |
| 35 |
Rich |
Archives