On 12/28/2016 6:40 PM, Yehuda Katz wrote: > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > <wr...@rowe-clan.net <mailto:wr...@rowe-clan.net>> wrote: > > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some integrate directly from source, and others > use a non-OS distribution. > > > I think a significant number of users of nginx add the official nginx > yum/apt sources and keep up to date that way > (http://nginx.org/en/linux_packages.html#mainline). > This is particularly true because the vendor-supplied version are so > old. You can see this in the w3techs data: nginx 1.10.2 came out in > October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8 > usage has similar trends. > > A possible solution to this would be to start publishing binaries in a > package-manager-accessible format. > I am confident it would see a much higher rate of adoption. > > - Y
I feel strongly about this... As a package builder/maintainer at $dayjob, this idea terrifies me. Given the huge variation in distributions and what is current on those platforms, the "best" option I see is to build for the least common denominator (minimum common libc, APR, APR-UTIL, openssl, openldap, etc). Otherwise, the package may only work on sufficiently modern installations. Things like Docker containers for the different distros are nice, but I'm not sure those are guaranteed to be current or accurately represent what an installation will look like. Additionally, vendors set different prefixes or split their configurations up differently meaning we would then have to bite off the work of creating vendor-specific packages (sucks for us) or force a standard installation format (sucks for operators of the servers). A really good illustration of this challenge is the layout differences between Debian and CentOS where even the name of the server binary is changed from "httpd" to "apache2" in the former distro. Or worse... we would have to bundle/vendor a copy of the dependencies inside the httpd package. This becomes a nightmare for the package builders because (as wrowe pointed out recently) it requires us to build these updated libraries and push the new package at some cadence as well as changing library search paths to potentially funky locations. It also becomes a challenge for server operators because a library now exists in two locations on the machine so compliance auditing gets forked (my httpd installation may be using openssl 1.0.2j but my postfix server may be using 0.9.8zh). Also, I'm sure it goes without saying, but we can't reasonably consider either approach without full CI... doing all this manually is unmaintainable (heh - ask me how I know). -- Daniel Ruggeri
