[94452] trunk/dports/www/nginx/Portfile

[Clemens Lang]

On Tue, Jun 19, 2012 at 04:37:52PM -0500, Ryan Schmidt wrote:
> Instead of having an ever-increasing number of variants for additional
> modules, would it be better to have subports? That way users could
> install subports for additional modules after the fact without having
> to rebuild the main port. The buildbot would be able to build and
> distribute them too (assuming compatible licenses)—the buildbot does
> not build non-default variants.

Yes and no.

As you say, using subports allows for more modularity and simplifies
separate installation and uninstallation of modules.

However, the downside is one avoidable build of the nginx core per
module, when building from source. This seems like a waste of time to
me.

Also, I'm not sure to what extent build-in modules can be packaged
separately, i.e. if what they install is contained in separable files,
potentially leaving us with a mess of variants and subports without a
clear indication to the user as to why a given module is a subport or a
variant.

Since what you're suggesting and what we've been doing with subports a
lot recently is effectively a way to generate more than one binary
package from a given source package (like e.g. Debian does, too[1])
maybe we should extend base to support this in a better way (avoiding
multiple rebuilds of common code)? I'm thinking of a keyword added to a
variant definition, marking it as separately packageable[2,3,4]. That
would allow users to add or remove variants later without rebuilding
common code. The buildbot could just build all variants marked as
separable in one step.

Summarizing, I'd say, yes that's a good idea, but I'd like to see better
support in base for this kind of thing before I implement it. Doing this
would also lift the limitation we currently have on the number of
variants (we're implicitly limited by the length of the tarball's
filename).


[1] That's exactly how *-dbg and *-dev packages are created on Debian.
If we ever wanted to go in the direction of separating development files
and debug symbols, having support in base for this would simplify this a
lot.

[2] we'd need a list of files to be included in this variant's package
somewhere

[3] having pre-/post-* hooks for those would probably be a good idea,
too

[4] even variants that change a file already installed by the base
package could be possible by providing an override mechanism.

-- 
Clemens Lang