httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <DRugg...@primary.net>
Subject Re: The Version Bump fallacy [Was Re: Post 2.4.25]
Date Fri, 30 Dec 2016 15:12:13 GMT
On 12/28/2016 6:40 PM, Yehuda Katz wrote:
> On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr
> <wrowe@rowe-clan.net <mailto:wrowe@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


Mime
View raw message