Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Patrick Steinhardt]

On Fri, Mar 23, 2018 at 03:25:12PM +0100, Arve Barsnes wrote:
> On 23 March 2018 at 14:27, Rich Freeman <rich0@g.o> wrote:
> > 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).
>
> Unless I'm misunderstanding, this is possible already in package.mask?
> If the mask is not permanent (for testing, as you mention), would
> there be any benefit in having it in profile instead?
>
> Putting misc/foo::gentoo in package.mask works fine either way.
> Probably <misc/foo-4::gentoo works as well, for your scenario above.
>
> I use this for the opposite scenario, I have */*::overlay in
> package.mask, and unmask only a particular package in package.unmask,
> to avoid bringing in a lot of overlay packages without having a
> particular need.
>
> Arve

This wouldn't help the maintainers of overlays, though, and puts
the burden on the user. One scenario where masks maintained in
overlays would be useful is the musl overlay, which carries
patches to various packages to have them compile with musl libc.
Obviously, I always want to use packages provided by the musl
overlay in case the same package from the Gentoo tree has build
failures. Even if the Gentoo-provided package gets updated, I'll
still want to use the older version from the musl tree, as the
build errors are likely to still exist.

If overlays were able to ignore packages from other repositories,
the musl overlay could simply mask out packages from the Gentoo
repository which are known to not compile on musl-based systems.
Like this, the user does not have to maintain these masks
manually, but they are already managed at a central place and
updated with the musl repository.

Patrick