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