Variants make it easier for the Maintainer to maintain multiple variants (in the conceptual, not Fink sense) of a package. It relieves what was becoming (became?) an unscalable mess of -pmXXX (and -pyXXX and -rbXXX, etc.) packages. Do you really believe that all those modules were tested with each perl version?
You are saying that the variants system makes it easier to keep dead and untested packages, exactly what I think is dangerous for Fink. I don't really want to go into what I think about -pm560 and -pm580 packages on Panther. As for -py22 and -py23, I don't see the need to have both variants for a given package. If it works with python23, why create a -py22 variant? And if it doesn't, you don't have two variants either.
Having a separate .info file for each variant makes it difficult for a Maintainer to keep variants in sync. It's too easy to forget to change one Depends package, or make a typo when applying the same tweak to a new revision of several files.
I admit that this may be true in some situations. But in real life, variants are not just differing configure options. You also have to change other parts of Compile- or InstallScripts, and there you can also forget to update some of the variants. Even for dependencies, you should consider each variant separately whether it needs them.
I am not opposed to others using the variant system, I only wanted to say that I don't see (yet?) how it can be useful for me, and that I see the danger of untested packages becoming more widespread.
-- Martin
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
