recommended "dependencies?"

[Randall Wood]

On 13 Feb 2007, at 01:04, Ryan Schmidt wrote:

> On Feb 12, 2007, at 11:12, Mike Roberts wrote:
>
>>> Then, I would say that you should have either an +rtf variant, or a
>>> +no_rtf variant, but never both. (What would it do if you did not
>>> specify any variant?)
>>
>> specifying both would have to be disallowed.
>>
>> my proposal is that the lack of a variant would be an indication that
>> the user has no preference and a port-specific default can be used.
>
> Ok. Consider a port that has a variant +with_rtf and, by your  
> request, also +without_rtf. The user specifies neither of these  
> variants. You say the default should be one or the other. Let's say  
> that the default is to include RTF support. So the +with_rtf  
> variant would do nothing different? Would contain no code at all?  
> Doesn't that seem weird?

Here is a quick example of how a port may work:

> configure.args --enable-foo --prefix=${prefix}   # --prefix in here  
> only for the example
>
> variant no_foo {
> 	configure.args-delete --enable-foo
> 	configure.args-append --disable-foo	# this line is often missing
> }

And how I would like to see the above port written:

> configure.args --prefix=${prefix}
>
> default-variants +enable_foo
>
> variant enable_foo conflicts disable_foo {
> 	configure.args-append --enable-foo
> }
>
> variant disable_foo conflicts enable_foo {
> 	configure.args-append --disable-foo
> }

The second version of the same file does the same thing, but I find  
that it is easier to work with. Note also that if the line that is  
commented "this line is often missing" is missing, then the port may  
install in a non-deterministic way, installing with foo enabled  
because the package's configure script auto-selects that.

>>> I have never used the variants.conf file so I have no comment on  
>>> that
>>> feature. Well, maybe I do: the comment would be that variants vary
>>> from port to port, so I can't see any usefulness in a global way to
>>> specify variants that should be used for all ports.

Many ports (particularly for web applications) require that a  
database be installed. Given that MacPorts supports at least 7  
different relational databases, standard variant names are useful to  
ensure that the database that I want to use for some particular port  
is used instead of the database that the port developer thought was  
best (again, a number of open-source web applications can run on  
mysql3/4/5 or postgresql7/8.0/8.1/8.2 or sqlite or ... If I want 1  
database server running then I need to be able to say: use mysql4 for  
all these applications...)

>> global variants such as darwin_8 exist and seem to be useful. their
>> usefulness diminishes beyond those few pre-defined names but i don't
>> believe this has to be the case.
>
> However, variants like darwin_8 and macosx are auto-selected by the  
> MacPorts infrastructure without the need to specify them in the  
> variants.conf file.
>
> You say it doesn't have to be the case that only these few variants  
> be useful globally. To you have a specific example of another kind  
> of variant that would be useful globally? I believe I saw that  
> gentoo has this concept too, and I wasn't sure how it was useful  
> there either.

Variants that are set to ensure that other ports are aware that  
certain capabilities exist on the system and should be taken  
advantage of would be useful, such as +with_gnome if GNOME is  
installed or +with_kde if KDE is installed or  
+with_postgresql<version> if postgresql version <version> is  
installed would all be useful default variants.

Randall Wood
rhwood at mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."