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
