Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 609338 - [Future EAPI] USE-conditional flag masking/forcing / implicit flag selection (was: GLEP 73)
Summary: [Future EAPI] USE-conditional flag masking/forcing / implicit flag selection ...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2017-02-14 13:00 UTC by Michał Górny
Modified: 2019-06-17 20:18 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-02-14 13:00:42 UTC
Consider the following example: a package supports SSL/TLS using either OpenSSL or GnuTLS as the backend. For this reason, it has:

  IUSE="ssl gnutls"

The flag descriptions being:

  ssl - enable support for SSL/TLS
  gnutls - Prefer GnuTLS over OpenSSL as the SSL/TLS backend

This is quite a common model in Gentoo these days. This implies that:

  -ssl -gnutls = no SSL/TLS
  -ssl  gnutls = no SSL/TLS
   ssl -gnutls = SSL/TLS using OpenSSL
   ssl  gnutls = SSL/TLS using GnuTLS

This has two disadvantages:

1. Some users are confused that USE=gnutls does not enable SSL/TLS by itself (i.e. is meaningless without USE=ssl),

2. we have two USE flag combinations that result in the same state.


To somehow circumvent that, we could use REQUIRED_USE:

  REQUIRED_USE="gnutls? ( ssl )"

or:

  REQUIRED_USE="!ssl? ( !gnutls )"

While this would clearly expose the dependency between ssl and gnutls flags, it would be PITA for users who e.g. don't want SSL on by default but want to prefer gnutls whenever applicable.


To provide a better solution, I'd like to propose having an ability to mask or force a flag conditionally, i.e. work alike regular REQUIRED_USE but without user interaction.

For example, the following snippet:

  REQUIRED_USE="!ssl? ( ~!gnutls )"

would mean 'if ssl is off, force gnutls off implicily [i.e. mask it]'. This could be visually presented similarly to regular masks, e.g. as:

  USE="-ssl [-gnutls]"

This could be similarly used to force something on, e.g. when it's implied:

  REQUIRED_USE="foo? ( ~xml )"

which would mean that enabling foo requires XML support in the package, and therefore implicitly exposes all the features that were controlled by the xml flag. Visually:

  USE="foo [xml]"


While this imposes some extra work on ebuild authors, it provides a reasonable alternative to regular REQUIRED_USE whenever the explicit choice is not required. Currently such cases are usually done implicitly by ebuild authors, and frequently not exposed correctly to the user.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-04-13 11:10:32 UTC
As has been pointed out, it might be better to have a new variable for it, e.g.:

  # forcedly disables USE=gnutls when USE=-ssl
  ENFORCED_USE="!ssl? ( !gnutls )"
  # forcedly enables xml when USE=foo
  ENFORCED_USE="foo? ( xml )"
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-09-08 18:02:44 UTC
This is now GLEP 73, and I think we could add it to tentative EAPI 7 list. However, I'm not sure if anybody will actually touch the horrible Portage internals to implement it...
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-10-04 20:27:19 UTC
Since Zac is progressing on the implementation, I think we can consider it initially feasible.
Comment 4 Ulrich Müller gentoo-dev 2019-06-17 12:03:22 UTC
From the 20171112 Council meeting:

[20:10:34] <mgorny> Automatic use enforcing (GLEP 73)
[20:10:38] <ulm> https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=dd298e8cd9b90cf623336f97f46e7e16feacdec3
[20:10:53] <dilfridge> to be clear, that proposal *replaces* glep73, right?
[20:10:54] <mgorny> as i said, the idea is to replace the GLEP73 by PMS

So, can we conclude that this feature won't be voted on as a GLEP, but as part of an EAPI, once an implementation is ready? Because then I would mark GLEP 73 as "Deferred" (unless you want to have it "Withdrawn").

Policy reference: GLEP 28, draft GLEP is inactive for more than 60 days.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-06-17 12:19:57 UTC
Either way, the implementation isn't progressing, so 'Deferred' sounds correct.
Comment 6 Larry the Git Cow gentoo-dev 2019-06-17 20:14:18 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/glep.git/commit/?id=e397ecc06ccd9df8bf741d8981ea10bb0c38db8d

commit e397ecc06ccd9df8bf741d8981ea10bb0c38db8d
Author:     Ulrich Müller <ulm@gentoo.org>
AuthorDate: 2019-06-17 20:12:56 +0000
Commit:     Ulrich Müller <ulm@gentoo.org>
CommitDate: 2019-06-17 20:12:56 +0000

    glep-0073: Deferred due to inactivity.
    
    Bug: https://bugs.gentoo.org/609338
    Signed-off-by: Ulrich Müller <ulm@gentoo.org>

 glep-0073.rst | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)