Alexis Ballier posted on Fri, 23 Nov 2012 18:11:30 -0300 as excerpted: > I remember I was more or less against [USE=introspection] being global > back then, but now I must admit its meaning is quite clear and that I > don't consider it local anymore (I enable/disable it in make.conf not > package.use), so I'd say go for it.
FWIW as a (long-time reasonably technical, even for gentoo) gentoo user, with very few exceptions, ALL my flags are in make.conf (actually, in a file /etc/portage/make/use, sourced from make.conf, as are several other files in that dir, make.conf itself is simply a bunch of source lines, but whatever), and thus "global" in terms of my own usage. I /consistently/ run with --ask/--pretend and verify flags on new packages, as well as checking any flag changes on existing packages, and making a system-wide-default decision once seems the easiest and most reasonable way to handle it, here. Then when I decide to change it for a package, I run equery hasuse and see what else uses that flag, then grep for it in both package.use/* and make/use, then change it globally if possible and run a --newuse -- pretend to see what changed, and decide then whether I want to keep the global change or if I want some packages each way, decide what I want the default to be, and put the others in package.use/*. There are only two exception packages, udev and ncmpc. Otherwise, even my package.use files are per-USE-flag. One ls is worth a thousand-word description: $ ls /etc/portage/package.use/ 0neg-amr 0neg-network doc secure-delete 0neg-bindist 0neg-openssl gtk sql 0neg-custom-cflags 0neg-qt4 minimal suid 0neg-deprecated 0neg-threads perl text 0neg-faac 0neg-webkit pic unlock-notify 0neg-gnutls 0neg-xml pipe webkit 0neg-gpg 0neg-zeroconf python zzpkg-ncmpc 0neg-kde 0neg-zlib sdl zzpkg-udev I'd guess that the global/local USE flag distinction is in practice lost on most users, and that of those that /do/ know the technical difference, likely most use make.conf for most local USE flags anyway, at least setting a system default, from which individual packages may deviate via package.use. That's certainly the case here. Given that, I'd argue that the global/local USE flag distinction is almost entirely maintainer convenience (tho I'm not sure it actually /is/ a convenience, at least for those who bother to fill in the per-package metadata description of what it's actually doing for that package) in any case, and I'd just as soon get rid of it, keeping a global description of ALL USE flags, regardless, and mandating appropriate metadata.xml local descriptions regardless as well. That way, global flags such as python would actually have reasonable per- package descriptions. Does it simply enable python script bindings? Does it enable installation of a bunch of python scripts? Does it enable a python-script extension for the package? What? The global python flag doesn't say, and far too few packages with the global python USE flag have a local description saying what it actually DOES. Unfortunately, that's the case with (raw guess) half the USE flag usage out there -- the gentooer has to actually read the ebuild to see what the flag does /for/ /that/ /package/, even tho the description SHOULD be in metadata.xml, thus exposed via equery uses, even for global flags. -- 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
