At 13:59 Uhr -0600 09.10.2002, Justin Hallett wrote: >there would be a set of work to do on the manager it's self, which would >be tricky but not soo bad, then there would be maintainer cooperation, >which I wouldn't be part of, i have no interest in maintining and testing >every single variant of everyone of my pkgs. We are a small team of >maintainers with lots to maintain already, and I wouldn't like none much >having others mess with my patch files to get other variants work while >breaking mine and me not knowing about it. I think the layout and idea is >good but the implementation of it lacks, welll pezzaz. Like for all the >extra work what does the maintainer get out of it other then more work?
Yup, I think you have a valid point there Justin. Of course, maintainers won't *have* to use the feature, though. But still it will cause overhead in the engine at least. People, don't forget: while Variants on the one hand are a cute thing and make it possible to custom taylor your Fink install, they also exponentiate the complexity of Fink and potentially of packages that use the feature. Added complexity means: * more bugs introduced to the package manager * more bugs introduced in packages * more hard-to-track-down run time bugs * added complexity for users * more work for maintainers On the pro side: * more flexibility for users: only install/compile what you really need * less "unnecessary" packages installed on your system * what else? So while I still think Variants are somewhat cool, I wonder if they are really worth the effort, or at least if they are worth the effort right now. Maybe they are. Maybe not. But I think before we storm ahead and somebody "just implements it", we should have a rock solid design of it. That said, of course certain things can only be found out by implementing and evaluating them - if somebody wants to open a CVS *branch* I am fine to it, but please stay away from HEAD CVS for now. And I definitly see no reason to switch to an XML format. The current format has proven with splitoffs that it is powerful enough to handle what we need. While I don't quite agree with the syntax of the example given on this thread, its general outline is what we are looking for I think. Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
