On Thu, Apr 08, 2004 at 02:48:37AM +0200, Martin Costabel wrote: > Daniel E. Macks wrote: > > > >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.
What about when fink gets perl583, and then people want packages for it? Should we not provide any -pm583, or scrap all the -pm581? Or just copy the .info and remember to change all the versioned Depends packages. If we provide both, then even the existing package probably has to be modified anyway (the manpage files probably conflict). So why not make it as easy as possible? When a new version of foo.pm is published that requires different tweaking than the previous, why should we have to duplicate all the tweaking info in multiple .info files? > 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? Because people want to use the a python module with python22! Or are you under the mistaken impression that all python modules are python-version-independent? > >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, The simplest usage, language-versions, makes it easy to make sure you don't accidentally have foo-pmXXX depend on bar-pmXXY. It is now easy to say "use the same XXX everywhere in this .info file". In fact, my initial proposal for variants was *just* perl-language-version. But people were concerned that this was a highly specialized feature, and that it should be implemented so that it could be extended in the future should the need arise. While I was working on it, the need arose, in the form of a small flood of "I want package X to be compiled with feature Y enabled" requests. So I tweaked the language-variant support to handle other types of things. > and that I see the danger of untested packages becoming more widespread. I agree. Committers have done an outstanding job thus far keeping the packages in the dists mostly-working. We'll just have to be extra-vigilant, and not be afraid to ask submitters "do you really need variant X?". dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- 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
