From: Alexis Ballier <aballier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
Date: Mon, 29 May 2017 20:00:37 +0200 [thread overview]
Message-ID: <20170529200037.2559f80a@gentoo.org> (raw)
In-Reply-To: <1496071993.31087.1.camel@gentoo.org>
On Mon, 29 May 2017 17:33:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Hello,
>
> For a long time we seem to be missing appropriate tools to handle USE
> flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all
> things considered, it has proven to be far from an optimal solution.
> I would therefore like to discuss adding a better tool to amend or
> replace it, to allow for automated handling of USE flag constraints.
This has been discussed in the past and I'm basically all for it. Some
more detailed comments below.
[...]
> 2. Specification
> ================
>
> 2.1. Forced USE flag constraints
> ================================
>
> This proposal introduces USE flag constraints that are meant to be
> solved automatically by the package manager. This is somewhat similar
> to REQUIRED_USE, except that it does not require the user to take any
> explicit action. In that regard, it is closer to conditional
> package.use.force/mask.
>
> In the basic form, it can be used to conditionally force a specific
> flag to be enabled or disabled. For example:
>
> foo? ( bar )
>
> would mean that the bar flag is implicitly enabled (forced) if foo is
> enabled as well. Appropriately:
>
> foo? ( !bar )
>
> would mean that the bar flag is implicitly disabled (masked) in that
> case.
All good here.
> It can also be used with multi-flag ??, ^^ and || constraints, i.e.:
>
> - ?? means that at most one of the flags can be enabled. If user
> configuration causes more than one of the flags to be enabled,
> additional flags are implicitly disabled (masked) to satisfy
> the constraint.
>
> - || means that at least one of the flags must be enabled. If user
> configuration causes none of the flags to be enabled, one of them is
> enabled implicitly (forced).
>
> - ^^ means that exactly one of the flags must be enabled. The behavior
> is a combination of both above constraints.
>
> The automated solving of USE constraints would require the developers
> to consider the implicit effect of the constraints they are writing.
Can you provide an efficient algorithm for the above syntax?
That is, given a set of +/- useflags forced by user, output the set of
effective useflags (or a rant if it is inconsistent).
Maybe I'm mistaken, but I doubt it is possible with n-ary constraints.
Now the extra question: Do those n-ary operators have any advantage ?
The point is to express some preference, below you suggest to leave
that to the user, but what about leaving that to the ebuild developer?
That way, e.g., || can be rewritten as implications: '|| ( a b c )'
becomes '!b? !c? a' meaning if none is enabled then a is automatically
enabled.
Note that with only unary constraints, computing the set of effective
useflags becomes trivial (linear in the # of useflags + constraints):
take the constraints as a list, solve the first one, add its
consequences (if any) to the set of forced useflags, continue with next
constraint or rant if the set of forced flags is inconsistent.
> 2.2. UI implications
> ====================
[...]
I really like that part. It becomes even simpler with only unary
constraints :)
[...]
> 2.4. Backwards compatibility
> ============================
>
> Before choosing the exact way of implementing this, we need to answer
> how far we want to provide backwards compatibility. In particular:
>
> a. Do we need the REQUIRED_USE requiring explicit user selection? Or
> can we rely completely on other solutions (automatic solving,
> pkg_pretend())?
>
> b. Would changing REQUIRED_USE behavior in place cause unintended side
> effects? Are we going to accept those effects until the packages are
> fixed? (e.g. selecting less preferred solution of constraint)
I would prefer changing REQUIRED_USE in a new EAPI. We definitely do
not need a new variable, REQUIRED_USE is good enough, but PMS has been
vague enough not to define that so we can't assume the selection of
auto-enabled useflags will be what was meant rather than something
completely stupid.
I'm even more inclined towards changing that in a new EAPI since using
the current REQUIRED_USE syntax seems to introduce yet another
exponential algorithm in the critical path of 'emerge -uDN world'...
[...]
> 2.5. Ebuild interface
> =====================
>
> This section is most flexible as I don't really care how it's done,
> as long as it's done. Depending on our preferences, and the answers to
> questions in the preceding section, the options include:
>
> 1. changing behavior of REQUIRED_USE retroactively -- i.e. making
> Portage start solving USE constraints automatically, and being able to
> rely on that a few months from now,
>
> 2. changing behavior of REQUIRED_USE in a future EAPI,
>
> 3. adding ENFORCED_USE with the new behavior in a future EAPI
> (and either keeping or removing REQUIRED_USE),
>
> 4. adding special syntax to REQUIRED_USE to indicate which constraints
> can be solved automatically,
>
> 5. adding special syntax to IUSE to indicate which flags can be
> enabled or disabled automatically via REQUIRED_USE (a little
> different from the exact proposal),
>
> 6. adding a dedicated variable to indicate USE_EXPAND sets that can be
> solved automatically via REQUIRED_USE (partial solution).
In that order:
2
1
4
_reopen_nominations
3 5 6
[...]
> 4. Comments
> ===========
>
> What do you think?
+1
Alexis.
next prev parent reply other threads:[~2017-05-29 18:00 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-29 15:33 [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE) Michał Górny
2017-05-29 16:30 ` Kent Fredric
2017-05-29 16:44 ` Michał Górny
2017-05-29 18:00 ` Alexis Ballier [this message]
2017-05-29 21:23 ` Michał Górny
2017-05-29 21:31 ` Ciaran McCreesh
2017-05-29 22:01 ` Ulrich Mueller
2017-05-29 22:05 ` Ciaran McCreesh
2017-05-30 7:47 ` Alexis Ballier
2017-05-30 8:05 ` Ulrich Mueller
2017-05-30 8:10 ` Alexis Ballier
2017-05-30 7:42 ` Alexis Ballier
2017-05-30 8:22 ` Ciaran McCreesh
2017-05-30 8:46 ` Alexis Ballier
2017-05-30 8:56 ` Ciaran McCreesh
2017-05-30 9:25 ` Alexis Ballier
2017-05-30 12:00 ` Ulrich Mueller
2017-05-30 14:33 ` Michał Górny
2017-05-30 15:33 ` Alexis Ballier
2017-05-30 18:11 ` Michał Górny
2017-05-30 18:46 ` Alexis Ballier
2017-05-31 6:55 ` Michał Górny
2017-05-31 7:24 ` Ciaran McCreesh
2017-05-31 7:34 ` Alexis Ballier
2017-05-31 7:35 ` Michał Górny
2017-05-31 7:51 ` Ciaran McCreesh
2017-05-31 7:54 ` Alexis Ballier
2017-05-31 7:56 ` Alexis Ballier
2017-05-31 7:32 ` Alexis Ballier
2017-05-31 8:03 ` Michał Górny
2017-05-31 8:38 ` Alexis Ballier
2017-05-31 13:04 ` Michał Górny
2017-05-31 17:39 ` Alexis Ballier
2017-05-31 19:02 ` Michał Górny
2017-05-31 22:52 ` Ciaran McCreesh
2017-06-01 8:55 ` Alexis Ballier
2017-06-01 21:31 ` Michał Górny
2017-06-02 6:37 ` Michał Górny
2017-06-02 11:18 ` Alexis Ballier
2017-06-02 13:49 ` Michał Górny
2017-06-02 11:27 ` Alexis Ballier
2017-06-02 13:55 ` Michał Górny
2017-06-02 15:09 ` [gentoo-dev] " Martin Vaeth
2017-06-03 11:00 ` [gentoo-dev] " Alexis Ballier
2017-06-03 15:33 ` Michał Górny
2017-06-03 16:58 ` Alexis Ballier
2017-06-04 8:59 ` Alexis Ballier
2017-06-05 7:55 ` Alexis Ballier
2017-06-05 14:10 ` Michał Górny
2017-06-05 17:24 ` Alexis Ballier
2017-06-05 18:10 ` Michał Górny
2017-06-05 18:15 ` Ciaran McCreesh
2017-06-06 12:08 ` Alexis Ballier
2017-06-06 17:39 ` Michał Górny
2017-06-07 6:49 ` Michał Górny
2017-06-07 8:17 ` Alexis Ballier
2017-06-07 9:27 ` Michał Górny
2017-06-07 9:56 ` Alexis Ballier
2017-06-09 9:19 ` Michał Górny
2017-06-09 11:41 ` Alexis Ballier
2017-06-09 12:54 ` Michał Górny
2017-06-09 14:16 ` Alexis Ballier
2017-06-09 16:21 ` Michał Górny
2017-06-11 16:05 ` Alexis Ballier
2017-06-12 9:08 ` Alexis Ballier
2017-06-12 19:17 ` Michał Górny
2017-06-13 10:27 ` Alexis Ballier
2017-06-13 22:13 ` Michał Górny
2017-06-14 9:06 ` Alexis Ballier
2017-06-14 12:24 ` Michał Górny
2017-06-14 13:16 ` Alexis Ballier
2017-06-14 13:57 ` Michał Górny
2017-06-14 14:09 ` Alexis Ballier
2017-06-15 15:59 ` Michał Górny
2017-06-15 16:07 ` Alexis Ballier
2017-06-15 16:13 ` Ciaran McCreesh
2017-06-15 16:19 ` Alexis Ballier
2017-06-15 16:22 ` Ciaran McCreesh
2017-06-15 16:30 ` Alexis Ballier
2017-06-15 16:32 ` Ciaran McCreesh
2017-06-15 16:37 ` Alexis Ballier
2017-06-15 16:45 ` Ciaran McCreesh
2017-06-15 16:55 ` Alexis Ballier
2017-06-15 17:04 ` Ciaran McCreesh
2017-06-15 17:30 ` Alexis Ballier
2017-06-15 17:48 ` Ciaran McCreesh
2017-06-15 18:09 ` Alexis Ballier
2017-06-15 17:38 ` Michał Górny
2017-06-15 18:05 ` Alexis Ballier
2017-06-14 14:28 ` Alexis Ballier
2017-06-02 12:16 ` Alexis Ballier
2017-06-02 13:57 ` Michał Górny
2017-06-02 14:56 ` [gentoo-dev] " Martin Vaeth
2017-06-02 15:19 ` Ciaran McCreesh
2017-06-02 16:26 ` Martin Vaeth
2017-06-02 18:31 ` Martin Vaeth
2017-06-02 1:17 ` [gentoo-dev] " A. Wilcox
2017-06-02 1:28 ` Rich Freeman
2017-06-02 1:33 ` A. Wilcox
2017-06-02 5:08 ` Michał Górny
2017-05-31 12:38 ` [gentoo-dev] " Duncan
2017-05-30 21:13 ` [gentoo-dev] " Kent Fredric
2017-05-30 8:29 ` Michał Górny
2017-05-30 9:34 ` Alexis Ballier
2017-05-30 14:12 ` Michał Górny
2017-05-29 19:24 ` Ciaran McCreesh
2017-05-29 19:42 ` Michał Górny
2017-05-29 19:44 ` Ciaran McCreesh
2017-06-05 8:26 ` Alexis Ballier
2017-06-09 12:35 ` Jason A. Donenfeld
2017-06-09 12:42 ` 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=20170529200037.2559f80a@gentoo.org \
--to=aballier@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