On 11/02/16 12:55, Rich Freeman wrote: > On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric <kentfred...@gmail.com> wrote: >> On 11 February 2016 at 15:51, Rich Freeman <ri...@gentoo.org> wrote: >>> In this case you just wouldn't enable python 2.7 support, but you >>> wouldn't disable it either. Portage would just pull it in where it is >>> needed. >> But you still need a mechanism in place if you *dont* want that to happen. >> ... >>> Unless of course you're suggesting "USE=-python_targets_python2_7" >> would not be "auto-enableable" > That is correct. > >> But then you're *still* requiring a tri-state USE. > Sure - it would be the same as how package-versions work today. > > Stick it in world, and you're pulling it in. > > Stick in in mask, and you're keeping it out. > > Don't do anything, and portage does what it thinks is best, guided by > profiles/etc. > >> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required > This is the only thing that would change. In all the other scenarios > you described the behavior would be the same as today. If you set > USE=-foo then you'll get the same errors you get today. > > Now, auto-unmask could still propose sticking USE=+foo in your > package.use if you have USE=-foo in your make.conf, which is already > the behavior today. If you've made any explicit USE setting in your > configuration, portage would never ignore it, but only suggest that > you change it. > > Perhaps it might make sense to introduce a new ~foo setting which > undoes a +/-foo in make.conf but doesn't set it either + or - in > package.use, allowing the setting to revert to the default behavior. > That would actually be useful independent of lazy use flags, but would > be more useful with lazy use flags. > >> Mentally keeping track of this accounting magic would be complicating >> matters. >> > I think you're overthinking this. It is completely analogous as to > what portage already does with package-versions. I don't have libjpeg > in my world file, and yet portage installs it, and I don't think about > it either way. If I wanted to pin a specific version of it or mask it > I could, but of course the preference of most users is to micromanage > as little as possible. > > Basically lazy use flags is intended for users to minimize the size of > their package.use files, just as they already minimize the size of > their @world and package.mask files today. > I would avoid complicating the USE flag system .. it's straightforward as it is, and has already been 'tweaked' by the auto-unmask feature, leading to large package.use files and has no support of per-category files (that I know of).
I would propose the introduction of a 'LUSE' flag (lazy-use or lightweight-use) which serves as a fall-back if the main USE system "fails" - ok this requires duplication of the existing checking system (and hence integration with portage) but it would allow you to set USE flags per system at install .. and you could 'tweak' LUSE flags to suit package implementations instead.
