RFC: Upstream vs distro packages

[3flex]

This module is inconsistent in the way it chooses which package source to install nginx from. By default, the package from the distro will be installed, unless (with current params.pp) the distro is Ubuntu Lucid, Precise or Trusty; Debian 6, 7 or 8; or Red Hat/CentOS 5, 6 or 7, in which case upstream nginx.org stable package will be installed.

The current setup means the module in principle prefers to install upstream package from nginx.org, but because params.pp must be updated as nginx updates the OSs they support, and this hasn't been happening, it creates a situation where an Ubuntu Trusty user will get nginx.org package, but a Xenial user gets the distro package, even though nginx.org makes one available.

Also, while nginx.org builds packages for SLES 12, this module doesn't use them, though it could be updated to do so.

Options, as I see them, to dealing with this more consistently:

1. Keep status quo. Module will theoretically install upstream stable package by default, and rely on more eyes on the module to ensure params.pp is updated in line with nginx.org OS support documented at http://nginx.org/en/linux_packages.html. Perhaps this is not much of an issue as I don't recall any recent issues/PRs to update this file, but if this module is all of a sudden updated it will change the package source for Ubuntu Xenial users which might be unexpected.
2. Use distro package by default. Requires no ongoing maintenance in this module.
3. Install upstream stable package by default for Ubuntu, Debian, Red Hat and CentOS, but do not hard code that support in params.pp. Only issue with this is that on day 1 of a new OS release nginx.org may not have packages, meaning the module will fail to install anything.

My personal preference is 2. It's easiest to maintain and predictable for users. Those who want upstream packages can easily change their config to get them. 1 or 3 is theoretically better for security for those distros that don't provide security support for nginx, but Ubuntu does since Trusty and Debian always has. I don't know Red Hat or CentOS's policy.

A further wrinkle is the new support for dynamic modules. nginx.org is building some (http://nginx.org/en/linux_packages.html#dynmodules). Debian is testing them (see libnginx-mod-* packages) and presumably they'll be in Debian 9 and future Ubuntu releases (likely from 17.04).

[ekohl]

When I installed nginx on CentOS 7 I got the upstream repository installed. Personally I prefer the EPEL version so I changed manage_repo to false. So another vote for option 2 from my side.

[juniorsysadmin]

Option 2 is the best option unless native packages lag significantly and/or new versions have new functionality that nearly all of the user base wants right away. eg. nodejs

[wyardley]

I had been thinking about this too.

I'm also mostly in favor of Option 2, though we might need to drop support for certain versions of some distros if we want new enough packages. It may also require some spaghetti code to deal with the differences (including the ones you mentioned in terms of newer vendor packages using dynamic modules, the different naming of those modules, etc.). I do think this should be the default option.

One big advantage of using the official upstream repos is that the version that gets installed across various distros / versions should be more consistent. Also, it avoids the issue with the version getting too old on distros that lock versions within major releases. So having this as an option that can still be enabled is a good one, I think.

For RHEL / CentOS, there may also be the issue of having some kind of dependency (hard or soft) on EPEL. I always think it's overkill to require an EPEL module explicitly, and since it's only needed on certain types of systems, may not be easy to list that requirement in metadata.json etc., but I think some / all of the needed packages come from EPEL.

The Passenger support option may also complicate things. It might make sense to always use the Phusion packages in that case (EPEL has passenger for EL7 at least, but it's still version 4).

@3flex: are you offering to make the changes?

[wyardley]

Seems like the direction of this has been pretty much determined. As far as the nuts and bolts, we can make some adjustments or docs changes in #914.