[gentoo-portage-dev] Re: Dynamic USE dependencies

[Duncan]

Rich Freeman posted on Thu, 02 Apr 2015 12:32:41 -0400 as excerpted:

> Out of curiosity, what is keeping us from having USE flag dependencies
> handled dynamically, in the same way that package dependencies are? If
> portage can figure out that I need libxml2 installed even if I don't put
> it in /var/lib/portage/world, why can't it figure out that I need it
> built with USE=icu even if I don't put that in /etc/portage/package.use?

Because USE flags are binary, with "not-yes" implying "no", while world 
set listings are binary, with "not-yes" implying "do it anyway if needed"?

OK, so the USE flag "not-yes" implied "no" /is/ a bit weak, packages omit 
the USE flag if they (or their maintainer) actually require the feature 
and simply hard-require what would otherwise be toggled by the USE flag, 
but by that same token, the very fact that the USE flag exists makes it 
an option for the admin that would toggle the flag, strengthening the USE 
flag's implied-no of the not-yes, and in any case, it's still *far* 
stronger than the "do-it-anyway-if-needed" of simply not listing a 
package in the world set.

Meanwhile, there is of course a way to have "no" for a world listing, put 
it in package.mask.  Similarly, there'a a way to enforce an explicit "no" 
for that implied by a USE "not-yes", by setting USE=-* at the beginning, 
and users who eventually get tired of having to worry about profile 
changes meaning implied USE flag changes, etc, may well eventually set 
it, as I did.  But that doesn't change the basic difference in what "not-
yes" is implied to mean in the two cases.


Changing the implied meaning of "not-yes" to match in both cases could 
certainly be done, but while I'm not opposed if the justification really 
is there, I think there's the potential here for a rather massive change 
in base assumptions, and if that is indeed what's involved, I believe 
it'd call for equally massive justifications.  OTOH, maybe you're 
thinking something a bit more incremental, which would accordingly 
require lower justification.  I'm just a bit worried...


... And I /still/ don't like that --ask, implies that I think it's OK for 
portage to write to my package.* files (even with config-protection), if 
I accidentally hit enter.  When the danger was simply that a package 
merge that would take some time and thus could easily be aborted, that 
was IMO reasonable.  The new situation is IMO far more borderline.  I'd 
be a whole lot more comfortable if some EMERGE_DEFAULTs parameter could 
be set to turn off portage's writing to package.* entirely, while keeping 
the old --ask package-merging /and/ use-flag/mask/keywording SUGGESTION 
behavior.

And I'm worried that the suggestion here is going further down that 
emerge writing its own config path, without (IMO) appropriate safeguards.

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