| 1 |
On 2018-03-23 06:27 AM, Rich Freeman wrote: |
| 2 |
> On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
>>>>>>> On Fri, 23 Mar 2018, Roy Bamford wrote: |
| 4 |
>> |
| 5 |
>>> games-emulation/sdlmame is masked. I have a higher version in my |
| 6 |
>>> overlay than the one in the tree and it gets masked too. |
| 7 |
>>> Its not a problem to me as I know how to manage it. Its just untidy. |
| 8 |
>> |
| 9 |
>> You still don't need a repository specific mask for this. Version |
| 10 |
>> specific masking and unmasking is entirely sufficient to express that |
| 11 |
>> the higher version is fine. |
| 12 |
>> |
| 13 |
> |
| 14 |
> It sounds to me that one of the intended behaviors is to tell portage |
| 15 |
> that for a particular package we want to ignore a particular |
| 16 |
> repository entirely. Suppose for example an overlay contains |
| 17 |
> misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want |
| 18 |
> portage to stick with foo-3 from the overlay. However, if the overlay |
| 19 |
> adds foo-4, or foo-4.1 we want this installed. A version mask would |
| 20 |
> not really cover this use case. |
| 21 |
> |
| 22 |
> IMO this sounds like a useful feature. Having it in profiles could |
| 23 |
> probably also be useful in some testing scenarios, such as when making |
| 24 |
> changes to a large number of packages that are already in the main |
| 25 |
> tree (think something analogous to a feature branch in git, where the |
| 26 |
> master branch continues to advance).> |
| 27 |
> Perhaps I'm misunderstanding the intent here, but I would suggest that |
| 28 |
> we describe the end goal in emails like these otherwise people focus |
| 29 |
> on the implementation details first. |
| 30 |
> |
| 31 |
|
| 32 |
Having the ability to specify a repository in atoms in profile is very |
| 33 |
useful to people who have large overlays and make heavy use of profiles. |
| 34 |
|
| 35 |
At my (and zmedico's) employer we use Gentoo heavily (all of our servers |
| 36 |
run it), and have a few large internal overlays and hundreds of internal |
| 37 |
profiles. There are packages in upstream Gentoo that we maintain an |
| 38 |
internal fork of, and it would be extremely useful if we could mask the |
| 39 |
::gentoo version of something so a version bump does not cause it to be |
| 40 |
installed instead of our forked version. |
| 41 |
|
| 42 |
To address ulm's comments, we want our internal fork to satisfy |
| 43 |
dependencies in ::gentoo for the package without having to fork dozens |
| 44 |
of ebuilds. Generally the forks are just for minor changes that do not |
| 45 |
break dependency compatibility, but do something that we need for |
| 46 |
whatever reason. |
| 47 |
|
| 48 |
In case there are questions about why we have hundreds of profiles, we |
| 49 |
use profile to define machine roles. Each internal machine type or role |
| 50 |
has a profile in one of our internal repositories. This allows us to |
| 51 |
manipulate USE flags, packages etc in each machine type with a fair bit |
| 52 |
of fine-grained control. Adding repository support to profile atoms will |
| 53 |
give us even more control, and having fine grained control over what we |
| 54 |
have on our servers is the main reason we run Gentoo. |
Archives