Discouraging variants [was: Re: port install efficiency issue]

C. Florian Ebeling florian.ebeling at gmail.com
Wed Mar 25 05:44:16 PDT 2009


>> 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.

Yes, doxygen dependency made me put ruby19 C API
docs into a variant as well.

Maybe such cases can with some justification be made
separate doc ports? I find that quite acceptable.


> Variant: +server. Usually bad. Example: mysql5 +server. Instead, create a
> separate mysql5-server port. (There is a ticket open for this specific
> issue.)

I agree on this as well.

> 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.

Wouldn't it make sense to provide a separate and conflicting whole
port maybe for this hten? I now that seems a bit farfetched, but
I'm trying to understand the implications of an hypothentical
removal of the variant concept altogether, which I would find
quite a clean scenario. I don't see a real blocker for such a move
yet.





-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com


More information about the macports-dev mailing list