Comment 5 for bug 1781971

Andres,

I think you and I need to discuss off-bug the extent of the changes that your proposal would entail. Preferably with Robie looped in because I had a bit of a more in-depth discussion with Robie earlier today via IRC of my concerns with this request, as well as three 'options' to solve this depending on the information made available. It's not as simple as making "one metapackage" as there is not "one nginx binary" in use here.

Essentially, as a summary of my concerns in the most basic form (in which an actual discussion would be more useful than back and forth emails or bug comments) is that to do what you're saying would necessitate the creation of **four new packages**, the renaming of two packages from that set of resultant packages completely, **breaking** upgradeability between Ubuntu releases, and including not three but four or five packages in Main.

The core problem is becasue we have **four separate NGINX binaries** of differing flavors:
 - nginx-full contains a more 'full' featureset including some third-party modules (this flavor was picked upstream in Debian)
 - nginx-light contains a lesser set of features, but enough to do the minimum requisite things for an average NGINX deployment (it has a few third party modules though).
 - nginx-extras has all the core modules and a bunch of extra modules from third parties.
 - nginx-core (the "Core NGINX flavor" really, which was decided upon with coordination between myself, the Server Team, and the TB) contains the nginx-full featureset minus third-party modules (needed to exclude those for the MIR done during the Trusty cycle).

To make a 'core' version of any of those requires first renaming nginx-core to some other name (which will break the ability to upgrade between releases safely with NGINX on board), and then split *four* flavors into nginx-{flavor} and nginx-{flavor}-core because the binaries differ across all four flavors. This is because the NGINX binaries do not have completely plug-and-play modules, and instead have a hybrid of dynamically-includable modules and **hard-coded compiled-into-the-binary** modules, making each flavor's nginx binary different from each other, so it's not easy to just change the -core package to just provide 'nginx' without any configuration.

This also will make any merges from Debian impossible because we've fundamentally altered the packaging at that point so much so that we will not be able to cleanly merge *anything* from Debian in terms of packaging changes, patches to package-specific things, etc.

This is just the tip of the iceberg in terms of how much your proposal will increase package management and maintainability complexities into the far future. As I said I brought all this up with Robie earlier today via IRC, it may be more prudent for us to have this discussion over a phone call or over a hangout rather than try and do back-and-forth here over bug responses/comments or email.