public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
Date: Sun, 9 Jul 2017 09:22:04 +0200	[thread overview]
Message-ID: <22881.55708.959987.414503@a1i15.kph.uni-mainz.de> (raw)
In-Reply-To: <1499549471.13515.3.camel@gentoo.org>

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

>>>>> On Sat, 08 Jul 2017, Michał Górny wrote:

> Nobody said anything about the next EAPI. The GLEP doesn't say a
> word about introducing it in a future EAPI.

> We're adding this as an optional (default off) FEATURE into Portage
> and we'll see how it works. As far as I'm concerned, we can enable
> it for all EAPIs without touching PMS at all.

Not sure if this is a good idea. First, there is the issue that we
would have different syntax for REQUIRED_USE, a looser one defined by
PMS and a stricter one defined by your GLEP, which can cause
confusion.

Second, and more important, introduction of an automatic solver would
inevitably lead to proliferation of REQUIRED_USE in the tree. However,
nothing would guarantee that the package manager on the user's side is
capable of solving the constraints automatically. The result would be
more emerge failures and asking for more micro-management of flags by
users.

Also, I believe that with an automatic solver, we would want to change
the policy defined in the devmanual which says that REQUIRED_USE
should be used sparingly [1]? When would we do this, if the feature
isn't connected to an EAPI? After a long enough waiting period?
Welcome back to pre-EAPI-0 times.

> In fact, the GLEP points out that the PMS does not specifically
> define how PMs are supposed to deal with ensuring that REQUIRED_USE
> is satisfied. Failing with poor error messages is just established
> historical Portage behavior. But if we get good test results and
> majority agreement, I see no reason why we couldn't start enabling
> it by default and eventually relying on it.

> After all, it wouldn't be the first non-PMS extension that we accept
> for user convenience yet do not require strictly.

See above. I fear it would cause pain for users whose PM doesn't
implement the feature.

> Of course, if you think it should be made obligatory or at least
> accounted for in a future EAPI, I have no problem with that. Ciaran
> might, however.

That is exactly what EAPI was invented for. Ebuild authors can only
rely on package manager support on users' side if the feature is
introduced with a new EAPI. Leaving the policy specified in [1] in
place forever is no good alternative, because then the full potential
of the automatic solver could not be exploited in ebuilds. (Also, how
would we enforce the devmanual policy?)

Ulrich

[1] https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

  parent reply	other threads:[~2017-07-09  7:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-08  9:43 [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints Michał Górny
2017-07-08 10:26 ` Ulrich Mueller
2017-07-08 11:49   ` Alexis Ballier
2017-07-08 12:01     ` Ciaran McCreesh
2017-07-08 14:14       ` Alexis Ballier
2017-07-08 14:23         ` Ciaran McCreesh
2017-07-08 14:39           ` Alexis Ballier
2017-07-08 17:58             ` Ciaran McCreesh
2017-07-08 18:16               ` Michał Górny
2017-07-08 19:05               ` Ulrich Mueller
2017-07-08 19:54                 ` Alexis Ballier
2017-07-08 18:25   ` Michał Górny
2017-07-08 18:58     ` Ulrich Mueller
2017-07-08 21:31       ` Michał Górny
2017-07-08 21:55         ` Kristian Fiskerstrand
2017-07-09  7:22         ` Ulrich Mueller [this message]
2017-07-09  7:57           ` Michał Górny
2017-07-09  8:29             ` Ulrich Mueller
2017-07-09  8:46               ` Michał Górny
2017-07-08 14:12 ` Alexis Ballier
2017-07-08 18:44   ` Michał Górny
2017-07-08 20:34     ` Alexis Ballier
2017-07-08 21:56       ` Michał Górny
2017-07-08 22:15         ` Michał Górny
2017-07-09  9:29         ` Alexis Ballier
2017-07-09 11:36           ` Michał Górny
2017-07-09 12:20             ` Alexis Ballier
2017-07-08 22:21 ` Daniel Campbell
2017-07-08 22:29   ` Michał Górny
2017-07-08 22:47     ` Daniel Campbell
2017-07-09  7:59       ` Michał Górny

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=22881.55708.959987.414503@a1i15.kph.uni-mainz.de \
    --to=ulm@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