public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Underscores in USE flags
Date: Sat, 21 Sep 2019 09:06:01 +0200	[thread overview]
Message-ID: <36698991841b76089eafa558f434f6f39f001880.camel@gentoo.org> (raw)
In-Reply-To: <20190921064355.GQ1128@gentoo.org>

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

On Sat, 2019-09-21 at 08:43 +0200, Fabian Groffen wrote:
> On 20-09-2019 22:53:53 +0200, Michał Górny wrote:
> > On Fri, 2019-09-20 at 13:46 -0700, Zac Medico wrote:
> > > If we take this underscore rule to its logical extreme, then we should
> > > rename python_targets_python3_7 to python_targets_python3-7, yes?
> > 
> > Believe me, I would have done that already if not the fact that with all
> > the dependency logic around here it would be totally destructive to all
> > Gentoo systems.
> 
> Honestly, with this reasoning, why force other packages to go through
> USE-flag renaming in that case?  A major consumer of USE_EXPAND isn't
> sticking to the rule, which makes any benefit of it moot.  Tools cannot
> assume the last underscore separates the USE_EXPAND var from its value,
> users cannot see what is the value either, without knowledge.

The major consumer is fixable.  Sure, it will take years but that's
better than leaving things wrong forever and saying wrong is good.

> 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.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  reply	other threads:[~2019-09-21  7:06 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 [this message]
2019-09-21  7:34         ` Fabian Groffen

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=36698991841b76089eafa558f434f6f39f001880.camel@gentoo.org \
    --to=mgorny@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