[gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Manuel Rüger]

Hello gentoo-dev,

I'd like to announce the NGINX_MODULES_STREAM use expand.

It will include nginx modules used for stream support.
Initially, there will be the following descriptions included:


access - This module allows limiting access to certain client addresses.
limit_conn - This module is used to limit the number of connections per
the defined key.
upstream - This module is used to define groups of servers that can be
referenced by the proxy_pass directive.


Cheers,

Manuel

[Michał Górny]

On Wed, 3 Feb 2016 23:29:49 +0100

Post by Manuel Rüger
Hello gentoo-dev,
I'd like to announce the NGINX_MODULES_STREAM use expand.
It will include nginx modules used for stream support.
access - This module allows limiting access to certain client addresses.
limit_conn - This module is used to limit the number of connections per
the defined key.
upstream - This module is used to define groups of servers that can be
referenced by the proxy_pass directive.

Could we please finally stop introducing global USE flags that are
going to only be used by a single package? make.conf already looks like
random mix of randoms these days, with some extra random cruft being
added every second Tuesday.

[Dirkjan Ochtman]

Post by Michał Górny
Could we please finally stop introducing global USE flags that are
going to only be used by a single package? make.conf already looks like
random mix of randoms these days, with some extra random cruft being
added every second Tuesday.

This is an interesting point, which I hadn't thought much about.

It seems USE_EXPAND is really popular. What does it bring that has all
these advantages over normal USE flags? It seems like APACHE2_MPMS,
APACHE2_MODULES and CURL_SSL could just be normal USE flags with some
REQUIRED_USE stuff.

Actually, I'm not really sure I understand why we can't use normal USE
flags for CPU_FLAGS_X86 or PYTHON_TARGETS, either.

Cheers,

Dirkjan

[Jason Zaman]

Post by Dirkjan Ochtman

Post by Michał Górny
Could we please finally stop introducing global USE flags that are
going to only be used by a single package? make.conf already looks like
random mix of randoms these days, with some extra random cruft being
added every second Tuesday.

This is an interesting point, which I hadn't thought much about.
It seems USE_EXPAND is really popular. What does it bring that has all
these advantages over normal USE flags? It seems like APACHE2_MPMS,
APACHE2_MODULES and CURL_SSL could just be normal USE flags with some
REQUIRED_USE stuff.
Actually, I'm not really sure I understand why we can't use normal USE
flags for CPU_FLAGS_X86 or PYTHON_TARGETS, either.

Which looks easier and nicer to you?

NGINX_MODULES_HTTP="access auth_basic autoindex browser charset
fancyindex fastcgi geo gzip limit_req limit_zone map memcached proxy
realip referer rewrite scgi spdy split_clients ssi upstream_check
upstream_ip_hash userid uwsgi"

or:

www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic nginx_modules_http_autoindex nginx_modules_http_browser nginx_modules_http_charset nginx_modules_http_fancyindex nginx_modules_http_fastcgi nginx_modules_http_geo nginx_modules_http_gzip nginx_modules_http_limit_req nginx_modules_http_limit_zone nginx_modules_http_map nginx_modules_http_memcached nginx_modules_http_proxy nginx_modules_http_realip nginx_modules_http_referer nginx_modules_http_rewrite nginx_modules_http_scgi nginx_modules_http_spdy nginx_modules_http_split_clients nginx_modules_http_ssi nginx_modules_http_upstream_check nginx_modules_http_upstream_ip_hash nginx_modules_http_userid nginx_modules_http_uwsgi

What is the problem with global flags? Its namespaced and never going to
interfere with other packages. The only difference is the descriptions
are in use.desc instead of use.local.desc, why does that matter?

-- Jason

[Dirkjan Ochtman]

Post by Jason Zaman
Which looks easier and nicer to you?
NGINX_MODULES_HTTP="access auth_basic autoindex browser charset
fancyindex fastcgi geo gzip limit_req limit_zone map memcached proxy
realip referer rewrite scgi spdy split_clients ssi upstream_check
upstream_ip_hash userid uwsgi"
www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic nginx_modules_http_autoindex nginx_modules_http_browser nginx_modules_http_charset nginx_modules_http_fancyindex nginx_modules_http_fastcgi nginx_modules_http_geo nginx_modules_http_gzip nginx_modules_http_limit_req nginx_modules_http_limit_zone nginx_modules_http_map nginx_modules_http_memcached nginx_modules_http_proxy nginx_modules_http_realip nginx_modules_http_referer nginx_modules_http_rewrite nginx_modules_http_scgi nginx_modules_http_spdy nginx_modules_http_split_clients nginx_modules_http_ssi nginx_modules_http_upstream_check nginx_modules_http_upstream_ip_hash nginx_modules_http_userid nginx_modules_http_uwsgi

Well, it seems like we could easily skip the _modules_http suffix, and
the difference would not nearly be so large.

The problem I have with it is that, as a user, it's yet another
concept to grasp and configure. Instead of just working with USE flags
(e.g. looking at use.desc or using ufed to review, configuring USE
flags in make.conf or package.use), I now have to find/learn a bunch
of new stuff. What packages use what USE_EXPAND things (e.g. apache
has two), what are valid values for all of these.

Where with simple USE flags, there is a single mechanism that I have
to learn and can apply across the board; with USE_EXPAND stuff, I have
to learn new stuff for each new package that adopts one or more
USE_EXPAND things.

So if this cosmetic expansion is the only advantage, that seems like a
relatively limited one (e.g. it could be improved a lot just by
formatting), and the trade-off of introducing all this extra
complexity doesn't make that much sense to me.

Cheers,

Dirkjan

[Alexis Ballier]

On Thu, 4 Feb 2016 13:01:25 +0100
Dirkjan Ochtman <***@gentoo.org> wrote:
[...]

Post by Dirkjan Ochtman
The problem I have with it is that, as a user, it's yet another
concept to grasp and configure. Instead of just working with USE flags
(e.g. looking at use.desc or using ufed to review, configuring USE
flags in make.conf or package.use), I now have to find/learn a bunch
of new stuff. What packages use what USE_EXPAND things (e.g. apache
has two), what are valid values for all of these.

They're just useflags, equery properly displays their description, and
you can set them in pacakge.use equally well, so you don't have to
learn anything new. You get a new way to set them via variables in
make.conf, which I agree is debatable, but doesn't add complexity.

[...]

Post by Dirkjan Ochtman
So if this cosmetic expansion is the only advantage, that seems like a
relatively limited one (e.g. it could be improved a lot just by
formatting), and the trade-off of introducing all this extra
complexity doesn't make that much sense to me.

Well, categorizing useflags, esp. for packages with a lot of them,
certainly helps me when I need to review what to enable and what not.

Alexis.

[Michał Górny]

On Thu, 4 Feb 2016 13:01:25 +0100

Post by Jason Zaman
Which looks easier and nicer to you?
NGINX_MODULES_HTTP="access auth_basic autoindex browser charset
fancyindex fastcgi geo gzip limit_req limit_zone map memcached proxy
realip referer rewrite scgi spdy split_clients ssi upstream_check
upstream_ip_hash userid uwsgi"

Well, the real issue here is that people are using USE_EXPAND as some
kind of 'here, upstream give us some grouped options, let's
thoughtlessly expose them all in some fancy USE_EXPAND without thinking
about usability of the solution!'

Of course, some of those flags make sense as USE flags. Some don't.
There are things that you practically always will want enabled. There
are things that should be controlled by global USE flags but instead
land in some custom USE_EXPAND because... because we can group it with
15 mildly relevant options!

So I have USE=zlib enabled because I want gzip support. But no, for
nginx I have to look through USE descriptions and find it's actually
nginx_modules_http_gzip because it happens that it is realized using
a loadable module!

[Kent Fredric]

Post by Michał Górny
Well, the real issue here is that people are using USE_EXPAND as some
kind of 'here, upstream give us some grouped options, let's
thoughtlessly expose them all in some fancy USE_EXPAND without thinking
about usability of the solution!'
Of course, some of those flags make sense as USE flags. Some don't.
There are things that you practically always will want enabled. There
are things that should be controlled by global USE flags but instead
land in some custom USE_EXPAND because... because we can group it with
15 mildly relevant options!
So I have USE=zlib enabled because I want gzip support. But no, for
nginx I have to look through USE descriptions and find it's actually
nginx_modules_http_gzip because it happens that it is realized using
a loadable module!

I figure it *might* make more sense for there to be a little more use
of that hardly used feature, /etc/portage/saved-config , especially
where:

a) No other packages are likely to depend on the package having that
feature enabled
b) There are no specific dependency requirements implicit in having a
feature enabled.

After all...

Post by Michał Górny
It is not uncommon to come across a package which has a very fine grained level of configuration options that go way
beyond what USE flags can properly describe.

-- savedconfig.eclass

However, nginx is clearly not one of the cases that would benefit a
lot here, as evidenced here:

nginx_modules_http_geoip? ( dev-libs/geoip )
nginx_modules_http_gunzip? ( sys-libs/zlib )
nginx_modules_http_gzip? ( sys-libs/zlib )
nginx_modules_http_gzip_static? ( sys-libs/zlib )
nginx_modules_http_image_filter? ( media-libs/gd[jpeg,png] )
nginx_modules_http_perl? ( >=dev-lang/perl-5.8 )
nginx_modules_http_rewrite? ( >=dev-libs/libpcre-4.2 )
nginx_modules_http_secure_link? (
userland_GNU? (
!libressl? ( dev-libs/openssl:0= )
libressl? ( dev-libs/libressl:= )
)
)
nginx_modules_http_xslt? ( dev-libs/libxml2 dev-libs/libxslt )
nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit?
( dev-lang/luajit:2= ) )
nginx_modules_http_auth_pam? ( virtual/pam )
nginx_modules_http_metrics? ( dev-libs/yajl )
nginx_modules_http_dav_ext? ( dev-libs/expat )
nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8
dev-libs/apr-util www-servers/apache )
nginx_modules_http_auth_ldap? ( net-nds/openldap[ssl?] )


And you'd hardly want all of those features to be turned on because it
might create a dependency graph far more severe than anyone wants.

And I'm guessing you can't just make people install ebuilds for each
module people want instead? ( And maybe have a single USE flag on the
main nginx that turning on installs a bunch of good default things
that people appear to always want easily )

[James Le Cuirot]

On Tue, 9 Feb 2016 11:34:12 +1300

Post by Kent Fredric
And I'm guessing you can't just make people install ebuilds for each
module people want instead? ( And maybe have a single USE flag on the
main nginx that turning on installs a bunch of good default things
that people appear to always want easily )

nginx is monolithic, if a package per module is what you meant.

[Kent Fredric]

Post by James Le Cuirot
nginx is monolithic, if a package per module is what you meant.

Yeah. That's what I was afraid of. Given what you're doing there,
there's practically no other way.

Other than to tell Gentoo users that you're giving them the "Maximal
power to choose" by demanding they maintain their own nginx ebuilds in
their own overlay if they want features outside a core set, or don't
want features inside a core set, and "hey dude, just work out that
stuff yourself".

And that approach just seems anti-gentoo.

[Luis Ressel]

On Tue, 9 Feb 2016 11:34:12 +1300

Post by Kent Fredric
nginx_modules_http_geoip? ( dev-libs/geoip )
nginx_modules_http_gunzip? ( sys-libs/zlib )
nginx_modules_http_gzip? ( sys-libs/zlib )
nginx_modules_http_gzip_static? ( sys-libs/zlib )
nginx_modules_http_image_filter? ( media-libs/gd[jpeg,png] )
nginx_modules_http_perl? ( >=dev-lang/perl-5.8 )
nginx_modules_http_rewrite? ( >=dev-libs/libpcre-4.2 )
nginx_modules_http_secure_link? (
userland_GNU? (
!libressl? ( dev-libs/openssl:0= )
libressl? ( dev-libs/libressl:= )
)
)
nginx_modules_http_xslt? ( dev-libs/libxml2 dev-libs/libxslt )
nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit?
( dev-lang/luajit:2= ) )
nginx_modules_http_auth_pam? ( virtual/pam )
nginx_modules_http_metrics? ( dev-libs/yajl )
nginx_modules_http_dav_ext? ( dev-libs/expat )
nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8
dev-libs/apr-util www-servers/apache )
nginx_modules_http_auth_ldap? ( net-nds/openldap[ssl?] )

Thanks for citing this, I think it demonstrates mgorny's point rather
nicely; we have global USE flags for many of those modules:

* nginx_modules_http_perl -> perl
* nginx_modules_http_auth_pam -> pam
* nginx_modules_http_auth_ldap -> ldap
* nginx_modules_http_geoip -> geoip
* nginx_modules_http_g(un)zip -> zlib
* nginx_modules_http_secure_link -> ssl

The following two ones aren't quite as obvious, but could also be
changed:
* nginx_modules_http_rewrite -> pcre
* nginx_modules_http_image_filter -> gd

Introduce new USE flags for the remaining few modules -- voilà, there
you go, no need for a new USE_EXPAND and the users will even get a
useful set of default modules enabled based on their global USE flags.

[Kent Fredric]

Post by Luis Ressel
Thanks for citing this, I think it demonstrates mgorny's point rather
* nginx_modules_http_perl -> perl
* nginx_modules_http_auth_pam -> pam
* nginx_modules_http_auth_ldap -> ldap
* nginx_modules_http_geoip -> geoip
* nginx_modules_http_g(un)zip -> zlib
* nginx_modules_http_secure_link -> ssl
The following two ones aren't quite as obvious, but could also be
* nginx_modules_http_rewrite -> pcre
* nginx_modules_http_image_filter -> gd
Introduce new USE flags for the remaining few modules -- voilà, there
you go, no need for a new USE_EXPAND and the users will even get a
useful set of default modules enabled based on their global USE flags.

OOohh. Right. Gotcha. This does strike me as an improvement.

The only way you could make that scheme better is having an early
stage in NGINX that shows which module are going to be built /based
on/ the USE flag combinations, and then something with savedconfig
could potentially bar building certain modules.

Post by Luis Ressel
Dependency control : USE flags representing the dep
Feature control: SavedConfig

And then the "Feature control" could be tightened up/managed with USE
flags used more sparingly when things depended on them.

The biggest downside of this is the disconnect for a user between
"What I want" and "What do I have to select to get what I want" ( For
instance, USE=pcre turning on rewrite support is weird ,

While mgorny is more focused on "Why do I have this dependency" not
"What feature do I want"

And this of course does nothing for us in regards to the large
collection of USE controlled SRC_URIs .....

Because NGINX is monolithic, but its sources are aggregated from a
bunch of different authors for some fun reason, sort of like having a
`linux-kernel` ebuild with a SRC_URI for every single vendor name (
*barf* )

I really do not envy the nginx maintainer.

[Luis Ressel]

On Tue, 9 Feb 2016 12:22:51 +1300

Post by Kent Fredric
The only way you could make that scheme better is having an early
stage in NGINX that shows which module are going to be built /based
on/ the USE flag combinations, and then something with savedconfig
could potentially bar building certain modules.

Post by Luis Ressel
Dependency control : USE flags representing the dep
Feature control: SavedConfig

And then the "Feature control" could be tightened up/managed with USE
flags used more sparingly when things depended on them.

That might be useful, if the maintainer is willing to implement it. :)

Post by Kent Fredric
The biggest downside of this is the disconnect for a user between
"What I want" and "What do I have to select to get what I want" ( For
instance, USE=pcre turning on rewrite support is weird ,

Sure, that's why I said these two (image_filter and rewrite) were less
obvious. I agree it'd be better to use a local 'rewrite' USE for the
rewrite module.

Post by Kent Fredric
While mgorny is more focused on "Why do I have this dependency" not
"What feature do I want"
And this of course does nothing for us in regards to the large
collection of USE controlled SRC_URIs .....

Yes, but we have those in other ebuilds, too, most of which don't use
USE_EXPAND. And this thread is supposed to be about the usage of
USE_EXPAND in nginx, right?

Post by Kent Fredric
Because NGINX is monolithic, but its sources are aggregated from a
bunch of different authors for some fun reason, sort of like having a
`linux-kernel` ebuild with a SRC_URI for every single vendor name (
*barf* )
I really do not envy the nginx maintainer.

Me neither. @mrueg or whoever's the maintainer: Thanks for sparing the
rest of us from this insanity. :)

Regards,
Luis Ressel

[Patrick Lauer]

Post by James Le Cuirot
On Tue, 9 Feb 2016 11:34:12 +1300

Post by Kent Fredric
nginx_modules_http_geoip? ( dev-libs/geoip )
nginx_modules_http_gunzip? ( sys-libs/zlib )
nginx_modules_http_gzip? ( sys-libs/zlib )
nginx_modules_http_gzip_static? ( sys-libs/zlib )
nginx_modules_http_image_filter? ( media-libs/gd[jpeg,png] )
nginx_modules_http_perl? ( >=dev-lang/perl-5.8 )
nginx_modules_http_rewrite? ( >=dev-libs/libpcre-4.2 )
nginx_modules_http_secure_link? (
userland_GNU? (
!libressl? ( dev-libs/openssl:0= )
libressl? ( dev-libs/libressl:= )
)
)
nginx_modules_http_xslt? ( dev-libs/libxml2 dev-libs/libxslt )
nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit?
( dev-lang/luajit:2= ) )
nginx_modules_http_auth_pam? ( virtual/pam )
nginx_modules_http_metrics? ( dev-libs/yajl )
nginx_modules_http_dav_ext? ( dev-libs/expat )
nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8
dev-libs/apr-util www-servers/apache )
nginx_modules_http_auth_ldap? ( net-nds/openldap[ssl?] )

Thanks for citing this, I think it demonstrates mgorny's point rather
* nginx_modules_http_perl -> perl
* nginx_modules_http_auth_pam -> pam
* nginx_modules_http_auth_ldap -> ldap
* nginx_modules_http_geoip -> geoip
* nginx_modules_http_g(un)zip -> zlib
* nginx_modules_http_secure_link -> ssl
The following two ones aren't quite as obvious, but could also be
* nginx_modules_http_rewrite -> pcre
* nginx_modules_http_image_filter -> gd
Introduce new USE flags for the remaining few modules -- voilà, there
you go, no need for a new USE_EXPAND and the users will even get a
useful set of default modules enabled based on their global USE flags.

And now I can't figure out what I need to enable to have "rewrite" work.
Good job!

The names match the internal module names, which is what I care about.
Figuring out if I need USE="zlib" or USE="compress" or even a combo is a
lot more effort and frustrating than having to enable the useflag that
has the name of the module.

It might not be 'pure' or very aesthetical, but we try to get stuff done
here.

[Luis Ressel]

On Tue, 9 Feb 2016 07:37:10 +0100

Post by Patrick Lauer
And now I can't figure out what I need to enable to have "rewrite"
work. Good job!
The names match the internal module names, which is what I care about.
Figuring out if I need USE="zlib" or USE="compress" or even a combo
is a lot more effort and frustrating than having to enable the
useflag that has the name of the module.
It might not be 'pure' or very aesthetical, but we try to get stuff
done here.

I agree concering rewrite, USE=rewrite would be better suited for that.
But zlib is a very obvious choice of USE flag, and most of the other
flags I listed had (nearly) verbatim the same names as upstream's
modules anyway (perl, geoip, auth_pam -> pam, auth_ldap -> ldap).

I think the fact that we can use global USE's this way matters very
much. If enable geoip or ldap in my make.conf, I expect packages with
optional geoip/ldap support to enable this support.

Also, if you wish to document this mapping in more detail, that's
exactly what we have the <use> tags in metadata.xml for. You can even
write whole sentences in there! :)

Regards,
Luis Ressel

[Luis Ressel]

On Tue, 9 Feb 2016 11:34:12 +1300

Post by Kent Fredric
nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit?
( dev-lang/luajit:2= ) )

This should of course also be changed to the global 'lua' useflag.
Currently, you're even mixing NGINX_MODULES and normal USE flags here
for maximum confusion.

[Kent Fredric]

Post by Jason Zaman
www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic nginx_modules_http_autoindex nginx_modules_http_browser nginx_modules_http_charset nginx_modules_http_fancyindex nginx_modules_http_fastcgi nginx_modules_http_geo nginx_modules_http_gzip nginx_modules_http_limit_req nginx_modules_http_limit_zone nginx_modules_http_map nginx_modules_http_memcached nginx_modules_http_proxy nginx_modules_http_realip nginx_modules_http_referer nginx_modules_http_rewrite nginx_modules_http_scgi nginx_modules_http_spdy nginx_modules_http_split_clients nginx_modules_http_ssi nginx_modules_http_upstream_check nginx_modules_http_upstream_ip_hash nginx_modules_http_userid nginx_modules_http_uwsgi

I used to do this sort of thing for the PYTHON_TARGETS stuff, but it
hurts way too badly.

So now instead I have a couple of convenience tools in `package.env` +
`env.d` instead. ( Queue many ewing )

Its really sad we can't just have what Paludis does, package.use side
support for USE_EXPAND.

www-servers/nginx normal_use_flags NGINX_MODULES: http_access
http_auth_basic http_autoindex

Or similar.

But I'd expect such a feature to make auto-unmask less elegant.

[Gordon Pettey]

Post by Jason Zaman

Post by Jason Zaman
www-servers/nginx nginx_modules_http_access

nginx_modules_http_auth_basic nginx_modules_http_autoindex
nginx_modules_http_browser nginx_modules_http_charset
nginx_modules_http_fancyindex nginx_modules_http_fastcgi
nginx_modules_http_geo nginx_modules_http_gzip nginx_modules_http_limit_req
nginx_modules_http_limit_zone nginx_modules_http_map
nginx_modules_http_memcached nginx_modules_http_proxy
nginx_modules_http_realip nginx_modules_http_referer
nginx_modules_http_rewrite nginx_modules_http_scgi nginx_modules_http_spdy
nginx_modules_http_split_clients nginx_modules_http_ssi
nginx_modules_http_upstream_check nginx_modules_http_upstream_ip_hash
nginx_modules_http_userid nginx_modules_http_uwsgi
I used to do this sort of thing for the PYTHON_TARGETS stuff, but it
hurts way too badly.
So now instead I have a couple of convenience tools in `package.env` +
`env.d` instead. ( Queue many ewing )
Its really sad we can't just have what Paludis does, package.use side
support for USE_EXPAND.
www-servers/nginx normal_use_flags NGINX_MODULES: http_access
http_auth_basic http_autoindex
Or similar.

But we can do exactly that, as of at least portage-2.2.24, possibly earlier.

[Jason Zaman]

[ ... ]

Post by Gordon Pettey

Post by Kent Fredric
Its really sad we can't just have what Paludis does, package.use side
support for USE_EXPAND.
www-servers/nginx normal_use_flags NGINX_MODULES: http_access
http_auth_basic http_autoindex
Or similar.

But we can do exactly that, as of at least portage-2.2.24, possibly earlier.

Whoa that I was unaware of. This is amazing and makes USE_EXPAND much
less important to me :D

-- Jason

[Michał Górny]

Post by Jason Zaman

On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric

[ ... ]

Post by Kent Fredric
Its really sad we can't just have what Paludis does, package.use side
support for USE_EXPAND.
www-servers/nginx normal_use_flags NGINX_MODULES: http_access
http_auth_basic http_autoindex
Or similar.

But we can do exactly that, as of at least portage-2.2.24, possibly earlier.

Whoa that I was unaware of. This is amazing and makes USE_EXPAND much
less important to me :D

Exactly. Furthermore, I wanted to deprecated setting flags via make.conf and switch to pure package.use alike paludis but met the usual resistance.

And now we have users that break their systems by misdeclaring ABI="x86_64"...

Post by Jason Zaman
-- Jason

[Matt Turner]

Post by Michał Górny

Post by Jason Zaman

On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric

[ ... ]

Post by Kent Fredric
Its really sad we can't just have what Paludis does, package.use side
support for USE_EXPAND.
www-servers/nginx normal_use_flags NGINX_MODULES: http_access
http_auth_basic http_autoindex
Or similar.

But we can do exactly that, as of at least portage-2.2.24, possibly earlier.

Whoa that I was unaware of. This is amazing and makes USE_EXPAND much
less important to me :D

Exactly. Furthermore, I wanted to deprecated setting flags via make.conf and switch to pure package.use alike paludis but met the usual resistance.

I don't remember such a thread, but I'm not surprised.

FWIW, I think the idea has merit.

[Alexis Ballier]

On Wed, 3 Feb 2016 23:48:49 +0100

Post by Michał Górny
On Wed, 3 Feb 2016 23:29:49 +0100

Post by Manuel Rüger
Hello gentoo-dev,
I'd like to announce the NGINX_MODULES_STREAM use expand.
It will include nginx modules used for stream support.
access - This module allows limiting access to certain client
addresses. limit_conn - This module is used to limit the number of
connections per the defined key.
upstream - This module is used to define groups of servers that can
be referenced by the proxy_pass directive.

Could we please finally stop introducing global USE flags that are
going to only be used by a single package? make.conf already looks
like random mix of randoms these days, with some extra random cruft
being added every second Tuesday.

yes please!
https://bugs.gentoo.org/show_bug.cgi?id=431408
3 years and counting :)