From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A2F0A1382C5 for ; Wed, 28 Mar 2018 04:45:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0077DE099F; Wed, 28 Mar 2018 04:44:56 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 95B35E0900 for ; Wed, 28 Mar 2018 04:44:55 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1f12v5-0001Zt-IR for gentoo-dev@lists.gentoo.org; Wed, 28 Mar 2018 06:42:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: New Portage fork: sys-apps/portage-mgorny Date: Wed, 28 Mar 2018 04:42:33 +0000 (UTC) Message-ID: References: <1521745426.836.25.camel@gentoo.org> <1521756383.23424.0.camel@gentoo.org> <22057579.quYvPxvz6Q@note> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d1057daa3) X-Archives-Salt: d5eff4dd-8b97-46d8-a63b-d23e6054e6df X-Archives-Hash: b04c988c391eb408307fab5a6e5ea45b 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