Wouldn't it make sense to provide a separate and conflicting wholeport 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
