public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Gilbert <floppym@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Underscores in USE flags
Date: Fri, 20 Sep 2019 16:13:08 -0400	[thread overview]
Message-ID: <CAJ0EP40r754wnUO8sYz-yAjLC2XXQAJ6a==E=FPWWqY3P8L+wA@mail.gmail.com> (raw)
In-Reply-To: <20190920190324.GA31594@cloudsdale.the-delta.net.eu.org>

On Fri, Sep 20, 2019 at 3:03 PM Haelwenn (lanodan) Monnier
<contact@hacktivis.me> wrote:
>
> [2019-09-20 13:24:45-0400] Mike Gilbert:
> > On Fri, Sep 20, 2019 at 12:55 PM Michał Górny <mgorny@gentoo.org> wrote:
> > > On Fri, 2019-09-20 at 12:41 -0400, Mike Gilbert wrote:
> > > > On Fri, Sep 20, 2019 at 12:11 PM Michał Górny <mgorny@gentoo.org> wrote:
> > > > > On Fri, 2019-09-20 at 11:46 -0400, Mike Gilbert wrote:
> > > > > > Recently, a large number of bugs were filed against packages that have
> > > > > > USE flag names which contain underscores. Apparently PMS prohibits
> > > > > > this except when the USE flag is part of a USE_EXPAND variable.
> > > > > >
> > > > > > https://projects.gentoo.org/pms/7/pms.html#x1-200003.1.4
> > > > > >
> > > > > > I'm not certain when this text was added to PMS, or how many of the
> > > > > > affected USE flags pre-date this policy.
> > > > > >
> > > > > > Portage seems to have no issue dealing with underscores, so this
> > > > > > doesn't seem to be solving any technical problem.
> > > > > >
> > > > > > I am pretty sure that renaming a bunch of USE flags will cause some
> > > > > > amount of end-user confusion, for very little benefit. Is enforcing
> > > > > > this part of PMS really worth it?
> > > > >
> > > > > And having packages with pretended-USE_EXPAND-that-does-not-work-as-
> > > > > USE_EXPAND is less confusing to the users?
> > > >
> > > > I doubt users immediately think "USE_EXPAND" when they see an underscore.
> > > >
> > > > Portage's seems fairly unambiguous to me. For example:
> > > >
> > > > % emerge -pv1O app-misc/foo
> > > >
> > > > These are the packages that would be merged, in order:
> > > >
> > > > [ebuild  N     ] app-misc/foo-0::local  USE="-modern_kernel"
> > > > PYTHON_TARGETS="python3_7" VIDEO_CARDS="radeon" 0 KiB
> > > >
> > > > Total: 1 package (1 new), Size of downloads: 0 KiB
> > > >
> > > > I don't think anyone would mistake "modern_kernel" for a USE_EXPAND
> > > > value  given the above.
> > >
> > > Look at the humongous list of flags on dev-libs/aws-sdk-cpp.  They all
> > > start with 'aws_targets' which is a clear attempt to emulate USE_EXPAND.
> > > Expect that they won't work as USE_EXPAND, user typing:
> > >
> > >   AWS_TARGETS="foo bar baz"
> > >
> > > will just wildly confused, and in the end this prefixing is just silly
> > > and causes the flag names to become awfully long.
> >
> > Ok, so you chery-picked one particularly horrible example. The Portage
> > output still puts them in USE="" section, though the user probably
> > won't see that given the massive USE flag list.
> >
> > My point still stands for many of the other packages in the repo that
> > don't have several dozen flags.
>
> While that's true for portage, it is false for gentoolkit with the
> `equery u <atom>` command.
>
> Following your original example it would be something like:
>
> % equery y app-misc/foo
> [ Legend : U - final flag setting for installation]
> [        : I - package is installed with flag     ]
> [ Colors : set, unset                             ]
>  * Found these USE flags for app-misc/foo-0::local
>  U I
>  - - modern_kernel            : Install init scripts for 3.18 or higher kernels with atomic rule updates
>  + + python_targets_python3_7 : Build with Python 3.7
>  - - video_cards_radeon       : VIDEO_CARDS setting to build driver for ATI radeon video cards
>
> And with a bunch more of USE flags (not with having to go to extremes like
> dev-libs/aws-sdk-cpp) it is very confusing a lot of time on machines where
> app-portage/eix would be overkill I had to check on another machine.

Ah, thank you for the example. I imagine equery is used quite
frequently for this sort of thing, so I'll concede the point.

It would be nice if there were some easy way to migrate package.use
settings; that's going to cause some grumbling from sysadmins.


  reply	other threads:[~2019-09-20 20:13 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 [this message]
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

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='CAJ0EP40r754wnUO8sYz-yAjLC2XXQAJ6a==E=FPWWqY3P8L+wA@mail.gmail.com' \
    --to=floppym@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