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

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

[Michał Górny]

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

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Thu, 22 Mar 2018 20:03:46 +0100
Michał Górny <mgorny@gentoo.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Michał Górny]

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 <mgorny@gentoo.org> 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

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1226 bytes --]

On 03/22/2018 01:17 PM, James Le Cuirot wrote:
> On Thu, 22 Mar 2018 20:03:46 +0100
> Michał Górny <mgorny@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Herb Miller Jr.]

On 03/22/2018 04:17 PM, James Le Cuirot wrote:
> On Thu, 22 Mar 2018 20:03:46 +0100
> Michał Górny <mgorny@gentoo.org> 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.

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

[Michał Górny]

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 <mgorny@gentoo.org> 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

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

[Consus]

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?

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

[Michał Górny]

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

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

[Geaaru]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

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 <mgorny@gentoo.org> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 2389 bytes --]

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 930 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Michał Górny]

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

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Francesco Riosa]

[-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --]



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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Franz Fellner]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

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 <vivo75@gmail.com>:

>
>
> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 2241 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Fri, 23 Mar 2018 11:53:40 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> 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.

I might have a better usecase for adding masks from overlays.

But its more for the usecase of "there isn't something wrong with that
package", but the more frequent usecase of "Portage is stupid and so we
have masks to coerce the right behaviour"

For example, if I had an overlay that's sole purpose was to
test/transition experimental versions of Perl, where the presumption
was that by installing said overlay, that you wished to upgrade to that
version of Perl, it might make sense to employ masks to prevent portage
doing dumb things.

And by "Dumb things", I mean some of the common problems I see where
portage tries to solve a blocker by downgrading Perl....

Its much simpler to just author a blacklist of "Look, these are things
that are known to be a mess, don't even consider installing them, with
a nice description of why this is nonsense"

Trying to achieve it by any other means simply tempts the problem to
reappear in another form, because everything *other* than package.mask
will have portage try to flip the USE flag to try to make it work, and
end up with people needing --backtrack=1000 and having it still not
work.

package.mask is at least a "look, we know this is nonsense, don't even
explore this line of reasoning" blunt instrument.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

W dniu sob, 24.03.2018 o godzinie 20∶02 +1300, użytkownik Kent Fredric
napisał:
> On Fri, 23 Mar 2018 11:53:40 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > 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.
> 
> I might have a better usecase for adding masks from overlays.
> 
> But its more for the usecase of "there isn't something wrong with that
> package", but the more frequent usecase of "Portage is stupid and so we
> have masks to coerce the right behaviour"
> 
> For example, if I had an overlay that's sole purpose was to
> test/transition experimental versions of Perl, where the presumption
> was that by installing said overlay, that you wished to upgrade to that
> version of Perl, it might make sense to employ masks to prevent portage
> doing dumb things.
> 
> And by "Dumb things", I mean some of the common problems I see where
> portage tries to solve a blocker by downgrading Perl....
> 
> Its much simpler to just author a blacklist of "Look, these are things
> that are known to be a mess, don't even consider installing them, with
> a nice description of why this is nonsense"
> 
> Trying to achieve it by any other means simply tempts the problem to
> reappear in another form, because everything *other* than package.mask
> will have portage try to flip the USE flag to try to make it work, and
> end up with people needing --backtrack=1000 and having it still not
> work.
> 
> package.mask is at least a "look, we know this is nonsense, don't even
> explore this line of reasoning" blunt instrument.

...except that it is also used to say 'this is experimental version,
unmask at will' and Portage wants to unmask stuff for you anyway. Well,
I mean the default configuration of Portage, not mine.

-- 
Best regards,
Michał Górny

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Sat, 24 Mar 2018 09:02:20 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> ...except that it is also used to say 'this is experimental version,
> unmask at will' and Portage wants to unmask stuff for you anyway. Well,
> I mean the default configuration of Portage, not mine.

Yeah, that default I find incredibly stupid tbh.

Auto-unmask use works nicely. Autounmask for package.mask and
accept_keywords is just madness I'd love to see stopped.

Its right up on my list of "portage doing ultra dumb stuff? Turn this
off".

I have it turned off in my defaults.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Sat, Mar 24, 2018 at 5:01 AM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Sat, 24 Mar 2018 09:02:20 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
>> ...except that it is also used to say 'this is experimental version,
>> unmask at will' and Portage wants to unmask stuff for you anyway. Well,
>> I mean the default configuration of Portage, not mine.
>
> Yeah, that default I find incredibly stupid tbh.
>
> Auto-unmask use works nicely. Autounmask for package.mask and
> accept_keywords is just madness I'd love to see stopped.
>

It can be useful, though obviously I review what is proposed before
merging the config changes.

I wouldn't put masks and keywords in the same bucket.  A mask
typically means that something is known to cause problems, while
missing keywords typically just means that it isn't known to work yet.
People running mixed-keywords will find themselves accepting keywords
a fair bit.


-- 
Rich

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 914 bytes --]

On 03/24/2018 02:01 AM, Kent Fredric wrote:
> On Sat, 24 Mar 2018 09:02:20 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
>> ...except that it is also used to say 'this is experimental version,
>> unmask at will' and Portage wants to unmask stuff for you anyway. Well,
>> I mean the default configuration of Portage, not mine.
> 
> Yeah, that default I find incredibly stupid tbh.
> 
> Auto-unmask use works nicely. Autounmask for package.mask and
> accept_keywords is just madness I'd love to see stopped.
> 
> Its right up on my list of "portage doing ultra dumb stuff? Turn this
> off".
> 
> I have it turned off in my defaults.

The defaults certainly do not work perfectly in all situations. However,
there are a vast number of situations where using --autounmask-continue
will make appropriate package.mask changes without the need for any user
intervention.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Sat, 24 Mar 2018 11:27:20 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> The defaults certainly do not work perfectly in all situations. However,
> there are a vast number of situations where using --autounmask-continue
> will make appropriate package.mask changes without the need for any user
> intervention.

Its really handy for use flags.

Its really handy for mixed arch/~arch where it promotes arch to ~arch as needed.

Its really really bad however to have a default of accepting ** and
package.unmask as a primary go-to solution.

That default gets people using broken openssl and experimental packages
blindly without them ever having intended on getting into experimental
waters.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]

On 03/24/2018 01:33 PM, Kent Fredric wrote:
> On Sat, 24 Mar 2018 11:27:20 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> The defaults certainly do not work perfectly in all situations. However,
>> there are a vast number of situations where using --autounmask-continue
>> will make appropriate package.mask changes without the need for any user
>> intervention.
> 
> Its really handy for use flags.
> 
> Its really handy for mixed arch/~arch where it promotes arch to ~arch as needed.
> 
> Its really really bad however to have a default of accepting ** and
> package.unmask as a primary go-to solution.

That only happens when dependency satisfaction fails by normal means.

> That default gets people using broken openssl and experimental packages
> blindly without them ever having intended on getting into experimental
> waters.

If people can't be bothered to understand the meaning of package.mask
and keywords changes, should they really be using Gentoo?
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Sat, 24 Mar 2018 13:44:49 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> That only happens when dependency satisfaction fails by normal means.

And when that happens, it is better to bail and go "Uh oh, something bad",
not "oh, right, lets install something that will likely make things
worse and additional work to fix"

Its a regular occurrence that we have to tell people about this on #gentoo.

> 
> > That default gets people using broken openssl and experimental
> > packages blindly without them ever having intended on getting into
> > experimental waters.  
> 
> If people can't be bothered to understand the meaning of package.mask
> and keywords changes, should they really be using Gentoo?

And its not *entirely* true that this is the case. Toralf used to
complain portage couldn't find a resoultion and would try unmasking
insane stuff in the process of tinderboxing.

But lo and behold, by removing the ability to unmask ** and
package.mask, he reported a significant improvement in the ability to
test.

"RTFM?" is a terrible response to "you have bad defaults that make
things break" because that default is *only* useful to people who would
consider using things that have *zero* expectation that they would work.

And that is not any majority demographic of the Gentoo user base.

Its not a useless feature, but its a feature that should only be
enabled after reading the documentation.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 2490 bytes --]

On 03/24/2018 07:26 PM, Kent Fredric wrote:
> On Sat, 24 Mar 2018 13:44:49 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> That only happens when dependency satisfaction fails by normal means.
> 
> And when that happens, it is better to bail and go "Uh oh, something bad",
> not "oh, right, lets install something that will likely make things
> worse and additional work to fix"

I don't think it's possible to have defaults that satisfy everyone. My
hope that the --autounmask default will be helpful to some people, and I
advise people to use --autounmask=n if it's not helpful.

> Its a regular occurrence that we have to tell people about this on #gentoo.

Normally, it emerge shows a message like the following when it creates
package.mask or ** keywords changes:

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

>>> That default gets people using broken openssl and experimental
>>> packages blindly without them ever having intended on getting into
>>> experimental waters.  
>>
>> If people can't be bothered to understand the meaning of package.mask
>> and keywords changes, should they really be using Gentoo?
> 
> And its not *entirely* true that this is the case. Toralf used to
> complain portage couldn't find a resoultion and would try unmasking
> insane stuff in the process of tinderboxing.
> 
> But lo and behold, by removing the ability to unmask ** and
> package.mask, he reported a significant improvement in the ability to
> test.

That's great. I really don't expect the default to work well in every
situation.

> "RTFM?" is a terrible response to "you have bad defaults that make
> things break" because that default is *only* useful to people who would
> consider using things that have *zero* expectation that they would work.

The --autounmask behavior only triggers when a dependency is encountered
that cannot be satisfied by normal means. So, it means that the user is
already using masked packages, or they have expressed a desire to
install a masked package.

> And that is not any majority demographic of the Gentoo user base.
> 
> Its not a useless feature, but its a feature that should only be
> enabled after reading the documentation.
But if the majority demographic is as you describe, then they shouldn't
be using anything having dependencies that require package.unmask or **
keywords changes.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

On Sat, 24 Mar 2018 21:43:41 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> But if the majority demographic is as you describe, then they shouldn't
> be using anything having dependencies that require package.unmask or **
> keywords changes.

Again, they *dont*, the problem is portage makes the mistake of
thinking they do.

This happens especially around virtuals where there is an existing
problem of portage not doing the right thing when perl-core/* exists in
some definition.

I don't have details on hand to give you as to how this happens,
but I've seen this happen often enough around packages *I maintain* and
*I* can't explain why portage is trying to install it, only that
--auto-unmask-keep-masks=y makes the problem mysteriously go away.

The question for me is not "auto unmask is good" vs "autounmask is
bad", autounmask is fine on its own and is very useful.

Its the default of --autounmask-keep-masks=n that I find short on value.

If anything, I suggest there needs to be an
--autounmask-keep-masks=conditional, or something, that narrows the
range of solutions portage will try and only attempt to unmask ** or
package.mask in the following conditions:

- An explicitly masked package/version is explicitly requested on the command line.
- A package is a direct dependency of of the above
- As above, but for the world file

That is, assume the only reason for masked packages to be considered is:
- The user in some way directly requested them
- A logical consequence of the user directly requesting a masked package


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 2033 bytes --]

On 03/25/2018 02:02 AM, Kent Fredric wrote:
> On Sat, 24 Mar 2018 21:43:41 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> But if the majority demographic is as you describe, then they shouldn't
>> be using anything having dependencies that require package.unmask or **
>> keywords changes.
> 
> Again, they *dont*, the problem is portage makes the mistake of
> thinking they do.
> 
> This happens especially around virtuals where there is an existing
> problem of portage not doing the right thing when perl-core/* exists in
> some definition.
> 
> I don't have details on hand to give you as to how this happens,
> but I've seen this happen often enough around packages *I maintain* and
> *I* can't explain why portage is trying to install it, only that
> --auto-unmask-keep-masks=y makes the problem mysteriously go away.

An issue like that involving REQUIRED_USE has been reported, and today
I've created a patch that corrects the problem:

    https://bugs.gentoo.org/622462

> The question for me is not "auto unmask is good" vs "autounmask is
> bad", autounmask is fine on its own and is very useful.
> 
> Its the default of --autounmask-keep-masks=n that I find short on value.
> 
> If anything, I suggest there needs to be an
> --autounmask-keep-masks=conditional, or something, that narrows the
> range of solutions portage will try and only attempt to unmask ** or
> package.mask in the following conditions:
> 
> - An explicitly masked package/version is explicitly requested on the command line.
> - A package is a direct dependency of of the above
> - As above, but for the world file
> 
> That is, assume the only reason for masked packages to be considered is:
> - The user in some way directly requested them
> - A logical consequence of the user directly requesting a masked package

It's possible that bug 622462 is not the only way to trigger this
problem. If anyone experiences a problem like this, then a bug report
would be appreciated.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

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 <pacho@gentoo.org> (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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <ulm@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.
>

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

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

[Arve Barsnes]

On 23 March 2018 at 14:27, Rich Freeman <rich0@gentoo.org> 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

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

[Geaaru]

Hi guys,

sys-devel/gcc::repos is only an example but from my side it is a real
example. 

Currently, Sabayon use our gcc ebuild so it is needed mask gentoo
version for rebuild sabayon-stage3 and now it is only possible (like
other packages) through file (from sabayon side):

/etc/portage/package.mask/00-sabayon.package.mask

My idea is permit to define this mask rules under sabayon overlay as
profile and/or as targets.

Interesting idea is opposite scenario propose by Barsnes about block
overlay packages.

Thank you to all for feedback about this proposal.

G.


On Fri, 2018-03-23 at 15:25 +0100, Arve Barsnes wrote:
> On 23 March 2018 at 14:27, Rich Freeman <rich0@gentoo.org> 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
> 

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

On Fri, Mar 23, 2018 at 03:25:12PM +0100, Arve Barsnes wrote:
> On 23 March 2018 at 14:27, Rich Freeman <rich0@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Georgy Yakovlev]

On Fri, 2018-03-23 at 16:23 +0000, Patrick Steinhardt wrote:
> 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

It's currently possible to do with a sort-of-automated script in 
/etc/portage/repo.postsync.d

i asked[1] ::musl about that and they do not want that.

the script provided the issue is just an example, it should check which
repo was just synced, also it does not care about versions, it just
masks the versionless atom, there are no any sanity checks.
it's just proof of concept.

But I find it useful on my underpowered APU system which runs musl.
I just want to avoid build failures, as each build takes a LOT of time.
I would not run that on a workstation, I'd better bump instead and port
the patches/ebuilds.
running ::musl is an active commitment, and it often requires
intervention and those should be contributed back if possible.


[1]https://github.com/gentoo/musl/issues/110

-- 
Georgy

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

[Patrick McLean]

On 2018-03-23 06:27 AM, Rich Freeman wrote:
> On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <ulm@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.

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 850 bytes --]

On 2018-03-23 18:44, Patrick McLean wrote:
> 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.

I have the same need, but it works for me: I have several packages in
/etc/portage/package.mask directory with content like

  <cat>/<pkg>::gentoo

to make sure the package from Gentoo repository isn't used.

But I guess you are talking about a different thing?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1071 bytes --]

On 03/26/2018 09:48 AM, Thomas Deutschmann wrote:
> On 2018-03-23 18:44, Patrick McLean wrote:
>> 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.
> 
> I have the same need, but it works for me: I have several packages in
> /etc/portage/package.mask directory with content like
> 
>   <cat>/<pkg>::gentoo
> 
> to make sure the package from Gentoo repository isn't used.
> 
> But I guess you are talking about a different thing?

The issue is that people are using profiles hosted in repositories other
than gentoo, complete with profiles.desc entries (eselect profile
supports this), and they would like to have the ability to use ::repo
atoms in these profiles.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]

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

[Vadim A. Misbakh-Soloviov]

Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on package 
from exact repo is much and much more needed functionality.

Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo too.
Then, I (or user) add other repo having pkg1 too. Or, say, gentoo maintainers 
bump pkg1 to a newer version (while I'm slacking a bit).
And my pkg1 is a bit different from gentoo's (let it be patchset, or, say, 
lua.eclass support for lua overlay).

So, that changes results in random unexpected behaviour as blocks, runtime 
breakage and so on.

And renaming all the packages to not collide with gentoo/other repos naming 
is, well, not an option, I think.


Or, another example:
I making pkg4 in my repo1, which depends on pkg3 from repo2 (where I 100% sure 
it fits all the requirements and the patchsets), while pkg3 in ::gentoo 
doesn't (and it can even have a bug about that opened for a century already).

Currently, it is no way to say "only dep-pkg from that exact repo is 100% 
works as expected", so there is still the chance, that someday pkg4 would fail 
to build because suddenly pkg3 was reinstalled from another "incompatible" 
repo...
And, honestly, current ways to resolve that issue (adding dummy-useflags, 
copy_here&rename, and so on) looks as very dirty hacks.

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

[Duncan]

Vadim A. Misbakh-Soloviov posted on Sun, 25 Mar 2018 17:13:28 +0700 as
excerpted:

> Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on
> package from exact repo is much and much more needed functionality.
> 
> Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo
> too. Then, I (or user) add other repo having pkg1 too. Or, say, gentoo
> maintainers bump pkg1 to a newer version (while I'm slacking a bit).
> And my pkg1 is a bit different from gentoo's (let it be patchset, or,
> say, lua.eclass support for lua overlay).
> 
> So, that changes results in random unexpected behaviour as blocks,
> runtime breakage and so on.

> Currently, it is no way to say "only dep-pkg from that exact repo is
> 100% works as expected", so there is still the chance, that someday pkg4
> would fail to build because suddenly pkg3 was reinstalled from another
> "incompatible" repo...

> And, honestly, current ways to resolve that issue (adding
> dummy-useflags, copy_here&rename, and so on) looks as very dirty hacks.

[Note that while the following is written using second-person "you", 
nothing personal or accusatory intended.  I simply started with second 
person and then realized half way thru that because it was written in 
second person it could be taken as offensive, which wasn't my intent, but 
didn't want to go back and adjust the whole thing to detached third-party 
viewpoint just to keep the technical point I had already made, so I chose 
the disclaimer method instead.  And as a second disclaimer, please see 
the last paragraph; maybe I'm missing the obvious...]

Actually, I'd argue that the problem as described is well within what USE 
flags are designed for, and that using a USE flag in this case makes 
/perfect/ sense.  Consider the description above:

* pkg2 deps on pkg1, both of which are in your repo.

* But your pkg1 is different in some way, custom patch set, say, or lua 
eclass support from its overlay.

* Your pkg2 deps on that difference.

Seems a perfect match for USE flag deps to me.  Make your pkg2 dep on pkg1 
conditional on a USE flag added to pkg1 when you changed it from what's 
likely to appear in gentoo or another overlay, making that change in 
behavior conditional on the USE flag and setting it up so flag-missing 
behavior is -flag.

Problem solved.

That creates an optional change in behavior toggled by a USE flag, and 
makes some other package dependent on that option by depending on that 
USE flag.  Isn't that exactly what USE flags and USE flag deps are 
/supposed/ to do?


Of course that pre-supposes that you want to go to all the work of doing 
it /correctly/ and making your change fully optional and togglable by 
individual per-package USE flags and deps that fit the individual cases, 
instead of taking the hacky shortcut of simply hard-coding your copy to 
do it your way, but "dummy USE flags" that do nothing but control the 
repo, because the behavior is hardcoded instead of setup via actually 
togglable USE flag aren't any more hacky than that hard-coding that makes 
them required in the first place.  It's really just part of the same 
hack, and if you're satisfied with the hacky hardcoded shortcut, it seems 
you should be satisfied with the hacky USE flag to make it work because 
you hardcoded the behavior as a shortcut instead of making it properly 
togglable, as well.

But if you /do/ want to simply take the expedient route and do hacks such 
as hardcoding choices (hey, I've taken the hardcoded behavior shortcut 
myself a few times) etc, and you're doing it pretty much globally, 
affecting many otherwise independent things thru the entire overlay, then 
it would seem to me that the most efficient method would be to simply do 
the fake-flag (call it overlayname-hardcoded or some such, obviously 
replacing overlayname as appropriate) hack by policy, adding it to your 
global USE flag settings in make.conf, and to every package as soon as 
you add it to your overlay.  Then you can depend on the flag as 
necessary, without having to worry about what it does in an individual 
package.

Tho even that's actually pretty comparable to how users work with global 
USE flags.  And if it's named overlayname-hardcoded or similar, you /are/ 
actually describing the USE flag, and how you're using it in the deps, 
reasonably accurately, even if there's no actual option to turn it off in 
the packages in your overlay.

... Tho it's quite possible there's holes in this argument that I'm 
simply not seeing, thus making my posting as much or more about asking 
others to point out the holes I can't see, so I /can/ see them, as it is 
about attempting to convince anyone of the correctness of my viewpoint as 
I'm posting it.  Sure I could be wrong, but if I am, please point it out 
so I can see it too! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Consus]

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.

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

[Consus]

Okay, this

	https://github.com/mgorny/portage-mgorny/issues/15

is a goddamn piece of sanity that Portage requires for a long time and
and it worth some $20 donations. Where to send moneyz?

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

[Michał Górny]

W dniu sob, 19.05.2018 o godzinie 18∶53 +0300, użytkownik Consus
napisał:
> Okay, this
> 
> 	https://github.com/mgorny/portage-mgorny/issues/15
> 
> is a goddamn piece of sanity that Portage requires for a long time and
> and it worth some $20 donations. Where to send moneyz?
> 

Thanks.  However, this really isn't something that deserves money.  I'm
pretty sure you'll find a better use for it.

-- 
Best regards,
Michał Górny

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

[Richard Yao]

> On May 22, 2018, at 4:35 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> W dniu sob, 19.05.2018 o godzinie 18∶53 +0300, użytkownik Consus
> napisał:
>> Okay, this
>> 
>>    https://github.com/mgorny/portage-mgorny/issues/15
>> 
>> is a goddamn piece of sanity that Portage requires for a long time and
>> and it worth some $20 donations. Where to send moneyz?
>> 
> 
> Thanks.  However, this really isn't something that deserves money.  I'm
> pretty sure you'll find a better use for it.

I suggest that you make an amazon wishlist and let people buy you things from there. Put some books on it that would be useful for development.
> 
> -- 
> Best regards,
> Michał Górny
> 
>