Max Horn wrote: > 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?
I suppose I see things differently. I think of adding variant support as systemizing something that already exists. Right now, there are several issues that variants should solve: 1. Quite a few packages already have ad-hoc variants (like the -ssl or -nox packages). 2. Users want or need features that aren't turned on in the Fink version of a package. 3. Users want or need to install things like libxml2 or xchat without the raft of dependencies (and associated downloads, compile time and/or disk usage) that come along with all the options that Fink compiles them with. 4. Users like to have small, stripped, optimized binaries; developers like the option of including debugging info and not optimizing. The current solutions to these issues cause problems. When more packages are installed because they are dependencies for unneeded options, the likelihood of interference between packages is higher, and there are more people who will be affected if there's a buggy buggy update (or one of those configure-script trojans). Ad-hoc variants sometimes go out of sync when the maintainer forgets to update one. When a feature is missing or unneeded, it causes more users to hack their .info files locally, or install from in /usr/local themselves. Perhaps half the 'bugs' I've dealt with have been from users who happened to have installed a non-standard package (.info hacked, from source, GNU-Darwin, etc) because 'it looked like Fink would take forever to install 73 packages'. The concepts of variants is a solution to all this, if implemented properly. I'm not too worried about testing--ideally, one should need to test just the no-options, all-options and default configurations. Then it can usually be assumed that they'll work in any combination, the same way we tend to assume that gnome-vfs-ssl or gnome-vfs will both work for a package that depends on 'em. Run-time bugs will generally not be any harder to track down then they are already--just install whatever variant is suspect, and do whatever you normally do to debug. It wouldn't be hard to make 'fink info' or 'fink list' report on variants so the user would know. Altogether, variants are a lot of work, but I think it will save work in the end. Of course, I'm not suggesting that we rush to implement them immediately. They will have to be very well planned before any code is written, and a new dependency resolver requires at least as much planning on top of that. Variants would be nice to have as early as possible as long as they're done well, but it's certainly something that could wait until post-1.0. By the way, the use of the Provides field, while great for some things, is not-so-great for variants. This is because apt/dpkg/dselect don't support versioned provides. Take a look at this: Package: foo--ssl Version: 1.2.3 Provides: foo Package: bar Depends: foo (>= 1.0.0) Apt would refuse to count foo--ssl as providing foo (>= 1.0.0) for package bar. Sucks, eh? We'll need instead for fink to auto-generate an extra dependency for foo-1.2.3 (note that the syntax here is arbitrary, I'm just aiming for brevity): Package: foo Version: 1.2.3 Variants: ssl, x11 Defaults: -ssl-nox11 Depends: iggy becomes in the control file Package: foo Version: 1.2.3 Depends: iggy, foo--ssl-nox11 (= 1.2.3) | foo--ssl-x11 (= 1.2.3) | ... and then of course it would generate a new control file for each possible variant. Ugly, but if it's automated who cares? :-) Dave ------------------------------------------------------- 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
