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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
