New Portage fork: sys-apps/portage-mgorny

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

New Portage fork: sys-apps/portage-mgorny

Michał Górny-5
Hello, everyone.

After 2+ years of repeating disagreements with Portage maintainer(s)
I have finally decided to fork Portage. My little fork uses technical
name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
and aims to focus on cleaning up code and adding useful features with
less concern for infinite bug-by-bug compatibility.

Detailed rationale in README [2].


Before installing
-----------------
This is a bleeding-edge, strictness-first fork of Portage. It is
intended for developers and power users mostly. Things will break.
You will eventually be asked to remove files deprecated 5+ years ago.
Developer mistakes will harm you (but someone needs to find them
and report them!)

Dynamic dependencies are off by default (following Council decision
from 3.5yr ago). If you haven't rebuilt your system recently, you may
need to use '--changed-deps' once. Afterwards, things should work fine
unless developers screw up, and then you should report bugs.

Only ~arch version at the moment.


Installing
----------
To switch to my fork of Portage, just:

  emerge -vn sys-apps/portage-mgorny

Note that you may need to:

  emerge --deselect sys-apps/portage app-portage/repoman

(repoman is integrated back into Portage)

You may also need to upgrade all revdeps of Portage since the newest
versions were bumped with updated dependencies.

Please note that due to misdesign, Portage will abort upon having to
unmerge itself on first install. However, it is a harmless failure
and portage[mgorny] will be installed already at the point, so upon
restarting it will just finish cleaning up.


Merge plan
----------
I do intend to regularly merge from mainline Portage, and preserve
reasonable compatibility (especially in terms of API). I also plan to
keep reasonably good commit quality as to make it easier for Portage
developers to merge back. However, this is not my primary concern.


Releases
--------
I plan to make frequent releases. I'm planning to version the releases
by sequential values of fourth version component from the last Portage
release. For example, since the last Portage release is 2.3.24, I have
just released portage-mgorny-2.3.24.1, the next release will
be 2.3.24.2, etc. until Portage 2.3.25 is released.

The releases are made against *git HEAD* and not respective Portage
versions, i.e. 2.3.24.1 is [2.3.24 + changes in mainline + my changes].
The matching versions are mostly meant to make >= deps easier, i.e. you
can reasonably assume portage-mgorny-2.3.24* will have all the new APIs
of portage-2.3.24.

The release notes [3] list any major changes I make. They do not list
the respective changes in mainline Portage, sorry.


Bugs, features and requests
---------------------------
I'm open to your feedback, including things that were rejected
by mainline Portage team. For best efficiency, please report bugs
on GitHub [4] and/or open pull requests [5].

Enjoy!


[1]:https://github.com/mgorny/portage
[2]:https://github.com/mgorny/portage/blob/master/README
[3]:https://github.com/mgorny/portage/releases
[4]:https://github.com/mgorny/portage/issues
[5]:https://github.com/mgorny/portage/pulls

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

James Le Cuirot
On Thu, 22 Mar 2018 20:03:46 +0100
Michał Górny <[hidden email]> wrote:

> After 2+ years of repeating disagreements with Portage maintainer(s)
> I have finally decided to fork Portage. My little fork uses technical
> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
> and aims to focus on cleaning up code and adding useful features with
> less concern for infinite bug-by-bug compatibility.

I hope you will continue with our efforts to drive regular Portage
forwards too. It's been a long road but also very productive.

I notice that your fork cannot be installed at the same time as regular
Portage. I think this will really hinder any interest in it. As
Gentoo developers, we obviously have to make sure things work with the
official package manager and that goes for you too. Would it be
possible for them to coexist? I'm not saying I'll try it though, just
making a suggestion. :)

--
James Le Cuirot (chewi)
Gentoo Linux Developer

attachment0 (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Michał Górny-5
W dniu czw, 22.03.2018 o godzinie 20∶17 +0000, użytkownik James Le
Cuirot napisał:

> On Thu, 22 Mar 2018 20:03:46 +0100
> Michał Górny <[hidden email]> wrote:
>
> > After 2+ years of repeating disagreements with Portage maintainer(s)
> > I have finally decided to fork Portage. My little fork uses technical
> > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
> > and aims to focus on cleaning up code and adding useful features with
> > less concern for infinite bug-by-bug compatibility.
>
> I hope you will continue with our efforts to drive regular Portage
> forwards too. It's been a long road but also very productive.
>
> I notice that your fork cannot be installed at the same time as regular
> Portage. I think this will really hinder any interest in it.

Making them co-installable would require creating divergent packages
and eventually making a huge mess of almost-identical-but-different
Python modules. It's not worth the effort, especially that the two
projects are not that divergent.

>  As
> Gentoo developers, we obviously have to make sure things work with the
> official package manager and that goes for you too. Would it be
> possible for them to coexist? I'm not saying I'll try it though, just
> making a suggestion. :)

As Gentoo developers, we have have to make sure things work with *all*
package managers. That's why we have standards and policies. Unlike
mainline Portage, portage[mgorny] follows those policies strictly
and therefore any ebuild that works with it should also work with
mainline Portage.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Zac Medico-2
In reply to this post by James Le Cuirot
On 03/22/2018 01:17 PM, James Le Cuirot wrote:

> On Thu, 22 Mar 2018 20:03:46 +0100
> Michał Górny <[hidden email]> wrote:
>
>> After 2+ years of repeating disagreements with Portage maintainer(s)
>> I have finally decided to fork Portage. My little fork uses technical
>> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
>> and aims to focus on cleaning up code and adding useful features with
>> less concern for infinite bug-by-bug compatibility.
>
> I hope you will continue with our efforts to drive regular Portage
> forwards too. It's been a long road but also very productive.
>
> I notice that your fork cannot be installed at the same time as regular
> Portage. I think this will really hinder any interest in it. As
> Gentoo developers, we obviously have to make sure things work with the
> official package manager and that goes for you too. Would it be
> possible for them to coexist? I'm not saying I'll try it though, just
> making a suggestion. :)
>
You can probably use the PATH/PYTHONPATH approach described here as long
as support for that has not been eliminated:

https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage
--
Thanks,
Zac


signature.asc (231 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Consus-2
In reply to this post by Michał Górny-5
On 20:03 Thu 22 Mar, Michał Górny wrote:
> Hello, everyone.
>
> After 2+ years of repeating disagreements with Portage maintainer(s)
> I have finally decided to fork Portage. My little fork uses technical
> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
> and aims to focus on cleaning up code and adding useful features with
> less concern for infinite bug-by-bug compatibility.
>
> Detailed rationale in README [2].

Do you have any roadmap?

Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Michał Górny-5
W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus
napisał:

> On 20:03 Thu 22 Mar, Michał Górny wrote:
> > Hello, everyone.
> >
> > After 2+ years of repeating disagreements with Portage maintainer(s)
> > I have finally decided to fork Portage. My little fork uses technical
> > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
> > and aims to focus on cleaning up code and adding useful features with
> > less concern for infinite bug-by-bug compatibility.
> >
> > Detailed rationale in README [2].
>
> Do you have any roadmap?
>

No. Just a few general ideas. It's Portage, so I don't expect anything
major to be able to happen.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Geaaru
Hi,

a bit out of topic (sorry in advance) but connect to eventually new portage feature...

for both portage and your fork I think that could be interesting add an extension to PMS for define inside profiles or targets masking of packages of a particular repslository. Currently PMS doesn't permit this but have this feature could be help users to define our profiles under overlays.

Something like this:

sys-devel/gcc::gentoo

Currently this is permitted only under /etc/portage but for distro based of gentoo or others use cases share our profiles directly under overlay could permit an easy and elegant way to share our customizations.

Unlucky this break specifications but I think that could be a fine new feature.

wdyt?

My cent.

G.

On Thu, Mar 22, 2018, 23:06 Michał Górny <[hidden email]> wrote:
W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus
napisał:
> On 20:03 Thu 22 Mar, Michał Górny wrote:
> > Hello, everyone.
> >
> > After 2+ years of repeating disagreements with Portage maintainer(s)
> > I have finally decided to fork Portage. My little fork uses technical
> > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
> > and aims to focus on cleaning up code and adding useful features with
> > less concern for infinite bug-by-bug compatibility.
> >
> > Detailed rationale in README [2].
>
> Do you have any roadmap?
>

No. Just a few general ideas. It's Portage, so I don't expect anything
major to be able to happen.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Zac Medico-2
On 03/22/2018 03:52 PM, Geaaru wrote:

> Hi,
>
> a bit out of topic (sorry in advance) but connect to eventually new
> portage feature...
>
> for both portage and your fork I think that could be interesting add an
> extension to PMS for define inside profiles or targets masking of
> packages of a particular repslository. Currently PMS doesn't permit this
> but have this feature could be help users to define our profiles under
> overlays.
>
> Something like this:
>
> sys-devel/gcc::gentoo
>
> Currently this is permitted only under /etc/portage but for distro based
> of gentoo or others use cases share our profiles directly under overlay
> could permit an easy and elegant way to share our customizations.
>
> Unlucky this break specifications but I think that could be a fine new
> feature.
>
> wdyt?
>
> My cent.
>
> G.
Bug filed: https://bugs.gentoo.org/651208
--
Thanks,
Zac


signature.asc (231 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Herb Miller Jr.-2
In reply to this post by James Le Cuirot
On 03/22/2018 04:17 PM, James Le Cuirot wrote:

> On Thu, 22 Mar 2018 20:03:46 +0100
> Michał Górny <[hidden email]> wrote:
>
>> After 2+ years of repeating disagreements with Portage maintainer(s)
>> I have finally decided to fork Portage. My little fork uses technical
>> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
>> and aims to focus on cleaning up code and adding useful features with
>> less concern for infinite bug-by-bug compatibility.
> I hope you will continue with our efforts to drive regular Portage
> forwards too. It's been a long road but also very productive.
>
> I notice that your fork cannot be installed at the same time as regular
> Portage. I think this will really hinder any interest in it. As
> Gentoo developers, we obviously have to make sure things work with the
> official package manager and that goes for you too. Would it be
> possible for them to coexist? I'm not saying I'll try it though, just
> making a suggestion. :)
>
Seems to also be blocked by other management tools such as perl-cleaner
and haskell-updater. I'd love to take it for a spin if you have any
suggestions on how to navigate the blocks.

https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/

----

Herb Miller Jr.

Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Michał Górny-5
W dniu pią, 23.03.2018 o godzinie 01∶01 +0000, użytkownik Herb Miller
Jr. napisał:

> On 03/22/2018 04:17 PM, James Le Cuirot wrote:
> > On Thu, 22 Mar 2018 20:03:46 +0100
> > Michał Górny <[hidden email]> wrote:
> >
> > > After 2+ years of repeating disagreements with Portage maintainer(s)
> > > I have finally decided to fork Portage. My little fork uses technical
> > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage),
> > > and aims to focus on cleaning up code and adding useful features with
> > > less concern for infinite bug-by-bug compatibility.
> >
> > I hope you will continue with our efforts to drive regular Portage
> > forwards too. It's been a long road but also very productive.
> >
> > I notice that your fork cannot be installed at the same time as regular
> > Portage. I think this will really hinder any interest in it. As
> > Gentoo developers, we obviously have to make sure things work with the
> > official package manager and that goes for you too. Would it be
> > possible for them to coexist? I'm not saying I'll try it though, just
> > making a suggestion. :)
> >
>
> Seems to also be blocked by other management tools such as perl-cleaner
> and haskell-updater. I'd love to take it for a spin if you have any
> suggestions on how to navigate the blocks.
>
> https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/
>

The instructions covered that. You need to upgrade those packages
to -r1.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Michał Górny-5
In reply to this post by Geaaru
W dniu czw, 22.03.2018 o godzinie 22∶52 +0000, użytkownik Geaaru
napisał:

> Hi,
>
> a bit out of topic (sorry in advance) but connect to eventually new portage
> feature...
>
> for both portage and your fork I think that could be interesting add an
> extension to PMS for define inside profiles or targets masking of packages
> of a particular repslository. Currently PMS doesn't permit this but have
> this feature could be help users to define our profiles under overlays.
>
> Something like this:
>
> sys-devel/gcc::gentoo
>
> Currently this is permitted only under /etc/portage but for distro based of
> gentoo or others use cases share our profiles directly under overlay could
> permit an easy and elegant way to share our customizations.
>
> Unlucky this break specifications but I think that could be a fine new
> feature.
>
> wdyt?

Nope. Diverging from the specification is entirely against the goal
of this fork. However, if mainline Portage supports that in non-spec-
breaking fashion, I'm going to merge it.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Ulrich Mueller-2
In reply to this post by Geaaru
>>>>> On Thu, 22 Mar 2018, Geaaru  wrote:

> for both portage and your fork I think that could be interesting add
> an extension to PMS for define inside profiles or targets masking of
> packages of a particular repslository. Currently PMS doesn't permit
> this but have this feature could be help users to define our
> profiles under overlays.

> Something like this:

> sys-devel/gcc::gentoo

Conceptually that makes no sense. sys-devel/gcc is the name of an
upstream package, so what does it even mean to mask it in one
repository but not in another? If it's the same package, then it
should behave in the same way, regardless of the repository its ebuild
it hosted in (or the package being installed, in which case it is no
longer in an ebuild repository).

If it is a different package however, then it should have a different
name.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Francesco Riosa-3


Il 23/03/2018 10:48, Ulrich Mueller ha scritto:

>>>>>> On Thu, 22 Mar 2018, Geaaru  wrote:
>> for both portage and your fork I think that could be interesting add
>> an extension to PMS for define inside profiles or targets masking of
>> packages of a particular repslository. Currently PMS doesn't permit
>> this but have this feature could be help users to define our
>> profiles under overlays.
>> Something like this:
>> sys-devel/gcc::gentoo
> Conceptually that makes no sense. sys-devel/gcc is the name of an
> upstream package, so what does it even mean to mask it in one
> repository but not in another? If it's the same package, then it
> should behave in the same way, regardless of the repository its ebuild
> it hosted in (or the package being installed, in which case it is no
> longer in an ebuild repository).
>
> If it is a different package however, then it should have a different
> name.
Sorry to say it bluntly but this make no sense at all, even changing a
USE flag make the package behave wildly differently.
Once we agree that an upstream (complex enough) package may have
different incarnations two ebuilds from different maintainers may please
differently the user.
I'm not sure this choice belong to profiles but not because same
upstream correspond to same files on filesystem.

>
> Ulrich



signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Roy Bamford-2
In reply to this post by Ulrich Mueller-2
On 2018.03.23 09:48, Ulrich Mueller wrote:

> >>>>> On Thu, 22 Mar 2018, Geaaru  wrote:
>
> > for both portage and your fork I think that could be interesting add
> > an extension to PMS for define inside profiles or targets masking of
> > packages of a particular repslository. Currently PMS doesn't permit
> > this but have this feature could be help users to define our
> > profiles under overlays.
>
> > Something like this:
>
> > sys-devel/gcc::gentoo
>
> Conceptually that makes no sense. sys-devel/gcc is the name of an
> upstream package, so what does it even mean to mask it in one
> repository but not in another? If it's the same package, then it
> should behave in the same way, regardless of the repository its ebuild
> it hosted in (or the package being installed, in which case it is no
> longer in an ebuild repository).
>
> If it is a different package however, then it should have a different
> name.
>
> Ulrich
>
Ulrich,

That has just irritated me.  The use case is sdlmame.

!!! The following installed packages are masked:
- games-emulation/sdlmame-0.195::Pi_aarch64 (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Pacho Ramos <[hidden email]> (18 Mar 2018)
# Fails to build (#634662), version bump long time pending (#596162).
# Removal in a month.

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.

With apologies to Pacho for citing his name in the worked
example.

--
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Franz Fellner
In reply to this post by Francesco Riosa-3
The dlang repository offers a gcc ebuild that adds the patchset to build the gdc. It's behind a USE-Flag. Still it is exactly the same as sys-devel/gcc::gentoo besides the additional feature.
But I don't think the dlang repo should mask gcc::gentoo.

2018-03-23 12:18 GMT+02:00 Francesco Riosa <[hidden email]>:


Il 23/03/2018 10:48, Ulrich Mueller ha scritto:
>>>>>> On Thu, 22 Mar 2018, Geaaru  wrote:
>> for both portage and your fork I think that could be interesting add
>> an extension to PMS for define inside profiles or targets masking of
>> packages of a particular repslository. Currently PMS doesn't permit
>> this but have this feature could be help users to define our
>> profiles under overlays.
>> Something like this:
>> sys-devel/gcc::gentoo
> Conceptually that makes no sense. sys-devel/gcc is the name of an
> upstream package, so what does it even mean to mask it in one
> repository but not in another? If it's the same package, then it
> should behave in the same way, regardless of the repository its ebuild
> it hosted in (or the package being installed, in which case it is no
> longer in an ebuild repository).
>
> If it is a different package however, then it should have a different
> name.
Sorry to say it bluntly but this make no sense at all, even changing a
USE flag make the package behave wildly differently.
Once we agree that an upstream (complex enough) package may have
different incarnations two ebuilds from different maintainers may please
differently the user.
I'm not sure this choice belong to profiles but not because same
upstream correspond to same files on filesystem.

>
> Ulrich



Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Ulrich Mueller-2
In reply to this post by Francesco Riosa-3
>>>>> On Fri, 23 Mar 2018, Francesco Riosa wrote:

> Il 23/03/2018 10:48, Ulrich Mueller ha scritto:
>> Conceptually that makes no sense. sys-devel/gcc is the name of an
>> upstream package, so what does it even mean to mask it in one
>> repository but not in another? If it's the same package, then it
>> should behave in the same way, regardless of the repository its
>> ebuild it hosted in (or the package being installed, in which case
>> it is no longer in an ebuild repository).

>> If it is a different package however, then it should have a
>> different name.

> Sorry to say it bluntly but this make no sense at all, even changing
> a USE flag make the package behave wildly differently.

Right, So you want USE dependencies, which we have. Nothing stops a
package in an overlay from having additional USE flags.

> Once we agree that an upstream (complex enough) package may have
> different incarnations two ebuilds from different maintainers may
> please differently the user.

Still, masking is the wrong way to express such preferences. If you
package.mask sys-devel/gcc then you say that something is wrong with
that package. Which I believe is not what you want to express here.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Ulrich Mueller-2
In reply to this post by Roy Bamford-2
>>>>> 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.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Consus-2
In reply to this post by Michał Górny-5
On 23:06 Thu 22 Mar, Michał Górny wrote:
> No. Just a few general ideas. It's Portage, so I don't expect anything
> major to be able to happen.

Is it possible to slowly migrate parts of sys-apps/portage to
portage-utils? I really like portage-utils's approach to make things
easier and modular. Also it's damn fast.

Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Rich Freeman
In reply to this post by Ulrich Mueller-2
On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <[hidden email]> 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.
>

I think it would be best to step back from terms like "masking" and
focus more on the intended behavior.

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.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: New Portage fork: sys-apps/portage-mgorny

Arve Barsnes
On 23 March 2018 at 14:27, Rich Freeman <[hidden email]> 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

123