Discouraging variants [was: Re: port install efficiency issue]
Ryan Schmidt
ryandesign at macports.org
Wed Mar 25 05:14:39 PDT 2009
On Mar 25, 2009, at 03:42, C. Florian Ebeling wrote:
> Maybe a guidelining positive list would be helpful, with
> reasons that usually warrant a variant. And if your
> reason is not on the list either collapse the variant
> into the main port or seperate it out into a port altogether.
>
> One problem with variants is that in the beginning it makes
> you feel like your a good citizen when you provide many.
> Misunderstood 'Mimize Coupling' thinking probably.
>
> Are there maybe better alternatives for any case
> where variants are used today?
Some examples from my ports:
Variant: +doc / +docs. Usually bad. Example: freetype +doc. Instead,
always install the documentation. (This specific issue was fixed in
r42509.) Corollary: If the documentation files must be built using a
heavy dependency such as doxygen, and users are unlikely to need the
documentation, leaving it in a variant is better. Example: libexif +doc.
Variant: +server. Usually bad. Example: mysql5 +server. Instead,
create a separate mysql5-server port. (There is a ticket open for
this specific issue.)
Example of something that has to be a variant: mysql5-devel
+innodb_plugin. Here you are choosing between the built-in InnoDB
functions that have been around forever vs. the new InnoDB functions
available in the InnoDB plugin. The plugin is not dynamically loaded;
rather, it's built into MySQL at compile time. You have to delete
part of the MySQL source and replace it with the source of the InnoDB
plugin.
More information about the macports-dev
mailing list