On 21-09-2019 09:06:01 +0200, Michał Górny wrote: > On Sat, 2019-09-21 at 08:43 +0200, Fabian Groffen wrote: > > Why not teach our tools (equery, quse, etc.) to print these USE-flags > > like Portage does? (looking them up to be valid expands) > > Then users have nothing to be confused about (no distinction between > > foo_bar and FOO="bar"), and new USE_EXPANDS cannot be > > silently/accidentially introduced. > > I don't see how that solves the problem. More tools having distinct > output don't change the fact that anyone with a bit of ebuild knowledge > will say 'this looks like USE_EXPAND' while looking at it, independently > of what some tools would say.
Well... someone with a bit of ebuild knowledge would see odd USE-flags. USE_EXPAND is a (bad) hack, of having some USE-flags mean something different, or resolve through something different, while in reality they really don't do anything odd. In fact, sometimes users have to use FOO="bar" (make.conf), while other times foo_bar needs to be used (e.g. use.mask, or IUSE=). Consistency would be nice, the real question is, what does USE_EXPAND actually try to achieve, and can we fix it properly in the next EAPI, such that repoman can also do the proper complaints about USE-flag (and USE_EXPAND-flag) naming by then. Back to the thread, the point is, these flags exist today, and renaming flags is not something to be considered harmless. As much as the recent renaming of lm_sensors to lm-sensors caused breakage (and still does, apparently some tools keep caches, etc.) also renaming USE-flags goes by problems, in particular for managed systems (Chef, Puppet). It's not a matter of just fixing the name for a USE-flag. This is saying nothing about whether or not we'd want to change the flag. It's about the impact of the change, and whether that is worth it for the noble aim of consistency or correctness. I believe this was the OPs point in this thread. Thanks, Fabian -- Fabian Groffen Gentoo on a different level
signature.asc
Description: PGP signature
