[gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Manuel Rüger]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 605 bytes --]

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Michał Górny]

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

On Wed, 3 Feb 2016 23:29:49 +0100
Manuel Rüger <mrueg@gentoo.org> wrote:

> 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.

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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Dirkjan Ochtman]

On Wed, Feb 3, 2016 at 11:48 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 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

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Jason Zaman]

On Thu, Feb 04, 2016 at 11:03:27AM +0100, Dirkjan Ochtman wrote:
> On Wed, Feb 3, 2016 at 11:48 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > 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

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Dirkjan Ochtman]

On Thu, Feb 4, 2016 at 11:27 AM, Jason Zaman <perfinion@gentoo.org> wrote:
> 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

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

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Alexis Ballier]

On Thu, 4 Feb 2016 13:01:25 +0100
Dirkjan Ochtman <djc@gentoo.org> wrote:
[...]
> 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.

[...]
> 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.

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Michał Górny]

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

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

> On Thu, Feb 4, 2016 at 11:27 AM, Jason Zaman <perfinion@gentoo.org> wrote:
> > 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!

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Kent Fredric]

On 9 February 2016 at 10:41, Michał Górny <mgorny@gentoo.org> wrote:
> 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...

>
> 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 )

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[James Le Cuirot]

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

On Tue, 9 Feb 2016 11:34:12 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> 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.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Kent Fredric]

On 9 February 2016 at 11:44, James Le Cuirot <chewi@gentoo.org> wrote:
> 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.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 11:34:12 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

>         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.

-- 
Luis Ressel

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Kent Fredric]

On 9 February 2016 at 11:59, Luis Ressel <aranea@aixah.de> wrote:
> 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.


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.

> 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.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 12:22:51 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> 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.
> 
> > 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. :)

> 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.

> 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?

> 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

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Patrick Lauer]

On 02/08/2016 11:59 PM, Luis Ressel wrote:
> On Tue, 9 Feb 2016 11:34:12 +1300
> Kent Fredric <kentfredric@gmail.com> wrote:
>
>>         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.
>
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.

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 07:37:10 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> 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

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Luis Ressel]

On Tue, 9 Feb 2016 11:34:12 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

>         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.

-- 
aranea

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Kent Fredric]

On 4 February 2016 at 23:27, Jason Zaman <perfinion@gentoo.org> wrote:
>
> 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.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Gordon Pettey]

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

On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric <kentfredric@gmail.com> wrote:

> On 4 February 2016 at 23:27, Jason Zaman <perfinion@gentoo.org> wrote:
> >
> > 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.

[-- Attachment #2: Type: text/html, Size: 1824 bytes --]

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Jason Zaman]

On Thu, Feb 04, 2016 at 04:35:44PM -0600, Gordon Pettey wrote:
> On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric <[1]kentfredric@gmail.com>
> wrote:
[ ... ]
>> 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

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Michał Górny]

Dnia 5 lutego 2016 07:38:44 CET, Jason Zaman <perfinion@gentoo.org> napisał(a):
>On Thu, Feb 04, 2016 at 04:35:44PM -0600, Gordon Pettey wrote:
>> On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric
><[1]kentfredric@gmail.com>
>> wrote:
>[ ... ]
>>> 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"...

>
>-- Jason


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Matt Turner]

On Fri, Feb 5, 2016 at 3:07 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 5 lutego 2016 07:38:44 CET, Jason Zaman <perfinion@gentoo.org> napisał(a):
>>On Thu, Feb 04, 2016 at 04:35:44PM -0600, Gordon Pettey wrote:
>>> On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric
>><[1]kentfredric@gmail.com>
>>> wrote:
>>[ ... ]
>>>> 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.

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Alexis Ballier]

On Wed, 3 Feb 2016 23:48:49 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Wed, 3 Feb 2016 23:29:49 +0100
> Manuel Rüger <mrueg@gentoo.org> wrote:
> 
> > 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.  
> 
> 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 :)