Given that package.use represents per-package USE, doesn't it follow that it should support -* like USE does? Portage already allows this in user configuration, but it doesn't work in profiles.
Would this apply to package.use{,.stable}.{mask,force} as well, or exclusively to package.use?
Should we also support '*' for symmetry? Then, do we also want to support using this on top of USE_EXPAND alike Portage, i.e. 'foo_bar_*'? Then, do we want to support '*' everywhere to avoid confusion? Then, do we want full fnmatch() syntax support to avoid confusion even more? At this point, I really think we shouldn't support '-*' anywhere and expect people to be able to type the few flags they want to actually disable verbosely.
(In reply to Ulrich Müller from comment #1) > Would this apply to package.use{,.stable}.{mask,force} as well, or > exclusively to package.use? Exclusively to package.use. Note that use.mask and use.force do not support -* (and it's not very useful for them anyway). (In reply to Michał Górny from comment #2) > Should we also support '*' for symmetry? Then, do we also want to support > using this on top of USE_EXPAND alike Portage, i.e. 'foo_bar_*'? Then, do we > want to support '*' everywhere to avoid confusion? Then, do we want full > fnmatch() syntax support to avoid confusion even more? Those are all very interesting questions, but lets consider them as essentially unrelated. We're concerned only with -* here, which has a well-known meaning in the context of the USE variable. > At this point, I really think we shouldn't support '-*' anywhere and expect > people to be able to type the few flags they want to actually disable > verbosely. Sure, we could drop the -* support from USE, in order to make it consistent with package.use behavior. However, that might upset some people who have been relying on it.
Maybe we should simply keep status quo? Starting from a blank slate might be more useful in global USE than on a per package basis (where the number of flags is limited).
(In reply to Ulrich Müller from comment #4) > Maybe we should simply keep status quo? Is the behavior defined or not? Is Portage free to "fix" bug 623850? > Starting from a blank slate might be more useful in global USE than on a per > package basis (where the number of flags is limited). That's reasonable enough, but portage allows this in user configuration, and used to allow it in profiles prior to this commit: https://github.com/gentoo/portage/commit/9e9c822aae0c3daab208175025b161d6d34877fe
(In reply to Zac Medico from comment #5) > Is the behavior defined or not? As I read the spec, it allows -* for USE (and other incremental variables): https://projects.gentoo.org/pms/6/pms.html#x1-620005.3.1 However, it doesn't mention this syntax for package.use: https://projects.gentoo.org/pms/6/pms.html#x1-590005.2.10 > Is Portage free to "fix" bug 623850? No (if my above interpretation is correct). > That's reasonable enough, but portage allows this in user configuration, > and used to allow it in profiles prior to this commit: > > https://github.com/gentoo/portage/commit/ > 9e9c822aae0c3daab208175025b161d6d34877fe That commit was 7 years ago, so I would conclude that _not_ supporting -* in package.use is established behaviour.
I'm happy enough if we resolve this as WONTFIX.
Let's WONTFIX it then. Feel free to reopen if somebody comes with a really good use case for it, and we can rediscuss.
(In reply to Ulrich Müller from comment #4) > Starting from a blank slate might be more useful in global USE than on a per > package basis (where the number of flags is limited). it is not limited. ebuilds are free to expand the set of flags they use at anytime. that means profile maintainers who are extending an existing profile while also precisely controlling flags on a subset of packages have to constantly monitor those packages to see what new flags the package maintainers decide to add. even if the new flags aren't enabled by default, the profiles being extended might change and turn flags on. only the use of -* allows profile maintainers to avoid surprises. like php and its wide array of modules based on global USE flags. or rsyslog and its wide array of modules based on global & local USE flags. /etc/portage/ package.use has symmetry with USE here which makes the profile omission all the more glaring.
