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