Consider the following example: a package supports SSL/TLS using either OpenSSL or GnuTLS as the backend. For this reason, it has:
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 )"
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:
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:
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.
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 )"
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...
Since Zac is progressing on the implementation, I think we can consider it initially feasible.
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.
Either way, the implementation isn't progressing, so 'Deferred' sounds correct.
The bug has been referenced in the following commit(s):
Author: Ulrich Müller <email@example.com>
AuthorDate: 2019-06-17 20:12:56 +0000
Commit: Ulrich Müller <firstname.lastname@example.org>
CommitDate: 2019-06-17 20:12:56 +0000
glep-0073: Deferred due to inactivity.
Signed-off-by: Ulrich Müller <email@example.com>
glep-0073.rst | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)