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
