public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Fabian Groffen <grobian@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Underscores in USE flags
Date: Sat, 21 Sep 2019 09:34:11 +0200	[thread overview]
Message-ID: <20190921073411.GT1128@gentoo.org> (raw)
In-Reply-To: <36698991841b76089eafa558f434f6f39f001880.camel@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2019-09-21  7:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 15:46 [gentoo-dev] Underscores in USE flags Mike Gilbert
2019-09-20 16:11 ` Michał Górny
2019-09-20 16:41   ` Mike Gilbert
2019-09-20 16:55     ` Michał Górny
2019-09-20 17:24       ` Mike Gilbert
2019-09-20 19:03         ` Haelwenn (lanodan) Monnier
2019-09-20 20:13           ` Mike Gilbert
2019-09-20 20:03         ` Michał Górny
2019-09-20 20:18           ` Mike Gilbert
2019-09-20 20:28             ` Michał Górny
2019-09-20 20:46 ` Zac Medico
2019-09-20 20:53   ` Michał Górny
2019-09-21  6:43     ` Fabian Groffen
2019-09-21  7:06       ` Michał Górny
2019-09-21  7:34         ` Fabian Groffen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190921073411.GT1128@gentoo.org \
    --to=grobian@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox