I agree with a lot of what Daniel says, and I'm in a similar role with maintaining my organization's httpd RPM packages.
However, I don't look at this suggestion so much as a replacement, but rather an additional option end users can use if they aren't up to the challenge of using sources, but can't get by with ancient builds in RHEL, etc. I personally doubt this would affect that many of the bigger users (let alone those on this list), as we would just keep using sources to keep up with what the LTS distros leave off (a 5+ year cycle is just too slow for the modern web tier). As someone who does distro packaging, I think this is completely the wrong distribution model, but it's also the quick and dirty one. Just throwing this out there, but a better middle of the road option for similar user coverage may be a more aggressive backporting of bleeding edge apache-related packages from development distros like Fedora to repositories maintained for the LTS distros. A lot of people already do this work independently, so perhaps much of the labor overhead could be knocked off with a bit more initial organizational effort, and referral/hosting support from the httpd project? Rick Houser Web Administration > -----Original Message----- > From: Daniel Ruggeri [mailto:drugg...@primary.net] > Sent: Friday, December 30, 2016 10:12 > To: dev@httpd.apache.org > Subject: Re: The Version Bump fallacy [Was Re: Post 2.4.25] > > 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
