I sometimes use NginX on Debian and maybe we really need to talk to Fabio
and Jose (the package maintainers in debian) as I don't see them post here
ever.

In my humble opinion there is no reason NginX's core should change from a
very useful (in terms of safety, debugging) feature to a less useful feature
only supporting an incomplete package.

The simplest debian-like nginx.conf is something like this:
(where N and M are appropriate numbers)
----
user www-data;
worker_processes N;
events {
worker_connections M;
}

http {
include mime.types;
include conf.d/*.conf;
include httpd.conf;
include sites-enabled/*;
}
----

On Mon, Mar 23, 2009 at 1:56 AM, Mark Alan <varia@e-healthexpert.org> wrote:

> Maxim Dounin wrote:
>
>> This is not bug, it's by design. And this allows to catch obvious
>> configuration errors easily - without even breaking working setup, since
>> nginx master process will refuse to reload configuration with bugs (and
>> hence old worker processes with correct configuration will continue to serve
>> requests).
>>
>
> I do think that the duplication check mechanism is very useful and among
> the strongest points of nginx. But I was not talking about that.
>
> nginx could still avoid breaking working setup by doing duplication checks
> and catch errors. It could have the best of both worlds by simply doing
> duplication check AFTER reading all .conf files, but still giving precedence
> to .conf files in the priority directory /conf.d/.
>
> I am thinking of, at least, /etc/php5/conf.d, /etc/apt/apt.conf.d,
> /etc/mysql/conf.d, /etc/apache2/conf.d. They all work rather well and
> respect /conf.d/*.conf precedence without breaking program's internal
> integrity.
>
> Also I should say that debian default config layout for nginx is rather
>> bad, since it provokes many configuration bugs.
>>
>
> So, the debian nginx package maintainer is sloppy.
> In your opinion what changes should be made to the Debian package to clean
> those bugs?
>
> > Some of them are easy to find thanks to duplication checks,
> > but some are really hard to find.
>
> Now, really helpful would be if you could provide us with a known list of
> those configuration bugs, in special those hard to find. Or, at least, point
> us to a web site were those configuration bugs are clearly listed for future
> reference.
>
>
> M.
>
>