[52043] trunk/dports/tex/texlive_base

[Ryan Schmidt]

On Jun 11, 2009, at 08:37, Daniel J. Luke wrote:

> On Jun 11, 2009, at 1:50 AM, Ryan Schmidt wrote:
>>> I find it simpler to set things up like the above example instead  
>>> (this avoids an extra variant and avoids having to indicate  
>>> conflicting variants).
>>
>> To me, it's the difference between whether the option, if it were  
>> presented to the user in a GUI, were presented as a checkbox or as  
>> a set of radio buttons.
>
> Since they produce the same output, and MacPorts doesn't present  
> checkboxes or radio buttons to the user, I don't think that that's  
> really a valid distinction.

I think it is valid, since several MacPorts GUIs have already been  
produced over the years, and Juan Germán is working on one for GSoC  
2009.

Radio buttons and checkboxes are well-established and well-understood  
metaphors and I see no compelling reason to ignore them and try to  
invent something new for the user to need to understand.


> The difference is that one method results in 2 variants that  
> conflict plus the 'magic' of default variants. Once you mix in the  
> registry not storing negative variants, I think you end up with  
> ugly user interaction if the user wants the non default one  
> (especially when he/she goes to upgrade it - unless that has been  
> fixed?)

Unconditionally using default_variants in a port is bad and will  
cause the problem you describe. Conditionally using default_variants  
only when none of the conflicting variants have been selected by the  
user should work fine. I have been using it in ports for years.

Ideally, ports should be coded so that a user need never use a  
negative variant (until that hypothetical future day when Registry  
2.0 lets us remember negative variants, at which point we can revisit  
this guideline).


> Having required features in a default variant also breaks the  
> conceptual model of the no variant version of the port being the  
> normal/recommended/featureful version with variants being special  
> cases.


I suppose I don't necessarily have that conceptual model. I mean, we  
already break that assumption with platform variants. And the  
default_variants feature has been in MacPorts for longer than I've  
been here, is documented, is part of the public port interface and is  
in use by ports. Until default_variants and platform variants are  
removed from MacPorts (and I have no reason to believe this will ever  
happen), we will have some ports that install with a variant even  
when you did not ask for one, and this need not cause the user any  
discomfort.


More justification for this way of using variants:


Case 1: Mini vMac can emulate a number of old Macintosh computers.  
For simplicity, the developer decided to offer no way to select this  
or any other options at runtime; everything must be selected at  
compile time. In the minivmac 2.x portfile, I implemented this by  
having variants for each Macintosh model you can emulate:

$ port variants minivmac
minivmac has the variants:
         mac128k: Emulate a Macintosh with 128K RAM and 2 drives
         mac512k: Emulate a Macintosh 512K with 512K RAM and 2 drives
         mac512ke: Emulate a Macintosh 512Ke with 512K RAM and 6 drives
         macplus: Emulate a Macintosh Plus with 4 MB RAM and 6 drives  
(default)
         macse: Emulate a Macintosh SE with 4 MB RAM and 6 drives
$

They are all marked as conflicting with one another, and if you don't  
select one, +macplus is selected for you, because that is the  
original and best-tested emulation and the one the developer  
recommends. To me, this variant presentation makes it clear that the  
user has a choice of five options, and which one will be selected by  
default.

If the +macplus variant were omitted, it would be less clear, and the  
user would have to consult perhaps the port's description to find out  
what happens if he does not select any variant. And it would be more  
difficult to represent clearly in a GUI.

Note that for the minivmac-devel 3.x portfile, in the interest of  
having fewer choices, I have removed these variants, and now always  
build all emulators, by running multiple make commands.


Case 2: PDFTK compiles using GCJ, which Xcode does not include.  
Therefore PDFTK needs to depend on a GCC port. Currently you can  
choose between using gcc41 or gcc42. The default, if the user has not  
chosen otherwise, is to use the newest, gcc42, via the +with_gcc42  
variant. (The "with_" variant naming is unfortunate and I wish it had  
not been used, but that's another matter.) When variants are used to  
select a compiler, having a variant for the default compiler also  
serves a very useful function. If some day a new version of PDFTK is  
released which can be compiled with a newer version of GCJ than that  
in gcc42, then #15420 can be resolved and a gcc44 variant can be  
added which will then be made the default. But a user who already had  
a prior version of PDFTK installed with, say, the gcc42 variant  
selected, will thus continue to use that compiler when upgrading the  
port. If there had been no variant for the default compiler, the user  
would be forced to install gcc44 at this point, which takes a  
nontrivial amount of time on the best hardware and an absolute  
eternity on older Macs.