public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Cc: "Dirkjan Ochtman" <djc@gentoo.org>,
	"Manuel Rüger" <mrueg@gentoo.org>,
	"Johan Bergström" <bugs@bergstroem.nu>
Subject: Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
Date: Tue, 9 Feb 2016 11:34:12 +1300	[thread overview]
Message-ID: <CAATnKFAoTvG6woN_8EW5+tSpv1d0efXP8xhgci2f213R=hDAyg@mail.gmail.com> (raw)
In-Reply-To: <20160208224119.14a513e1.mgorny@gentoo.org>

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


  reply	other threads:[~2016-02-08 22:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 22:29 [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM Manuel Rüger
2016-02-03 22:48 ` Michał Górny
2016-02-04 10:03   ` Dirkjan Ochtman
2016-02-04 10:27     ` Jason Zaman
2016-02-04 12:01       ` Dirkjan Ochtman
2016-02-04 12:22         ` Alexis Ballier
2016-02-08 21:41         ` Michał Górny
2016-02-08 22:34           ` Kent Fredric [this message]
2016-02-08 22:44             ` James Le Cuirot
2016-02-08 22:56               ` Kent Fredric
2016-02-08 22:59             ` Luis Ressel
2016-02-08 23:22               ` Kent Fredric
2016-02-08 23:33                 ` Luis Ressel
2016-02-09  6:37               ` Patrick Lauer
2016-02-09  8:18                 ` Luis Ressel
2016-02-08 23:07             ` Luis Ressel
2016-02-04 12:17       ` Kent Fredric
2016-02-04 22:35         ` Gordon Pettey
2016-02-05  6:38           ` Jason Zaman
2016-02-05 11:07             ` Michał Górny
2016-02-06 20:08               ` Matt Turner
2016-02-04 10:14   ` Alexis Ballier

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='CAATnKFAoTvG6woN_8EW5+tSpv1d0efXP8xhgci2f213R=hDAyg@mail.gmail.com' \
    --to=kentfredric@gmail.com \
    --cc=bugs@bergstroem.nu \
    --cc=djc@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=mrueg@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