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

[Jeremy Lavergne]

>>>> 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.
>
> For the previously listed variants (+doc, +server), these can be  
> made into separate ports; however, what do you do in cases such as  
> the curl port?  For example, the curl port has the variants openldap  
> and sftp_scp.  I don't imagine many users would need these features,  
> but there are users that use them. Enabling these features by  
> default is not reasonable because their dependencies are heavy  
> (specifically openldap), but making these two variants a separate  
> port also doesn't make sense. The variants openldap and sftp_scp are  
> not mutually exclusive; I may want to enable both. Without variants,  
> I don't see how we could handle these types of situations.

I always thought default variants took care of making things simple  
for the novice yet allowed you to override what variants were used if  
you were advanced.

Granted, that's just the facade of easiness, when it does supply you  
more choices.

I guess what I'm saying is we can have the average user depend on the  
defaults to be the "easy" route and the advanced user can care about  
the variants.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090325/bd238733/attachment.bin>