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