[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