Hi Folks: It seems I've opened a can of worms. Sorry.
My original concern was whether a significant number of users are turning away from fink in favor of other options, and if so, whether this was due to reasons that are valid and ought to be addressed. The first response snapped me out of post-Rumsfeld bliss pretty quickly: "The big problem, as I see it, is that the fink project doesn't have the manpower to put fink into the kind of better shape..." and " .... in the long run, I don't see how the community will be able to sustain [competing package management systems]". Most of the remaining responses focused on a subsidiary question I asked -- whether the stable/unstable demarcation was the source of dissatisfaction and whether the definitions and possibly the criteria for the demarcation should be revised. There seemed to be a consensus (among those who replied) that this was indeed something that was worth reconsidering. Since this exchange arose as a product of my own paranoia (losing fink is about as attractive a future as losing my spouse, as both considerably lighten my workload), please permit me to backtrack a bit, and suggest the following be assessed in a manner a bit more objective than an email poll among the converted (us): 1. Is there in fact significant dissatisfaction? (Lots of people use alternatives like MacPorts, but that doesn't mean that they have all rejected fink. If someone uses an alternative, or does stuff manually, as a matter of taste, I personally don't think we should waste time worrying about this. If people are finding fink too obtuse or cumbersome or out of date or limited or whatever, especially if for reasons that are either a matter of perception or are easily fixed, that is another matter.) 2. Are there concerns in addition to the stable/unstable demarcation we ought to pay attention to? 3. Is there anything a moron like me, who can't program his way out of a wet paper bag, but relies heavily upon fink, can do to help? (More generally, is there a way of better incorporating the interest and efforts of the user community so that they become invested in fink and develop some sweat equity?) 4. Is there a better forum for this sort of discussion (sorry if I posted to the wrong place)? ====================== Now if you will indulge me a bit, here are my thoughts on these: 1. I think, based on my interactions with a fair number of users in the scientific community, that there are genuine concerns. 2. Yes. 3. I have some ideas. 4. Beats me. I have nothing that remotely approaches a statistically significant sampling, but I have encountered some of the following concerns on a regular enough basis that I think we should consider these valid. There are doubtless others. I'm going to phrase these as *suggested* solutions just to try to end this on a positive note. 1. Simplify the prerequisites. ----------------------------------------- I get a lot of emails from people having trouble with the X11 requirements, Xcode issues and updates, and so forth. This has prompted me to formulate the following suggestions: a. Make installation of X11.app the default pre-requisite (and provide an escape route for the few that won't or can't use that option). I may be mistaken, but I think all the stuff in X11.SDK are open-source header files. If so, maybe fink can have a way of directly installing this if missing, rather than just warning about it. b. Have Fink use its own compiler set exclusively, so it is not dependent upon Xcode. In addition to lightening the installation and frequent update burden for users, it would help to assure that fink would not experience unpleasant surprises with Xcode updates. Make these compilers (g++, gcc, gfortran, g95, g77, etc) available as binary debian packages immediately. c. Put code in /sw/bin/init.(c)sh to set the DISPLAY properly for multi-users of X11.app for fast user switching, or create a package that makes profile.d files to d the same (I can do that, BTW). 2. Make the painful stuff a priority for binary distribution. ------------------------------------------------------------------------ ------ a. One of the most common complaints (including my own) is that I can issue "fink update-all" and everything starts recompiling, which on my 800 MHz laptop, can take many hours. I stopped doing updates on all but one of my ppc computers, and instead serve all my debian packages from my server computer to all my others. There HAS TO be a better way. I got rid of KDE because of the intense recompilation requirements, and the probability for some little glitch preventing an update became too large. So if complicated packages that take a long time to compile, especially ones that are frequently dependencies for other packages, could be made immediately available as a binary distribution, this would greatly ease the pain. b. If necessary to ease the burden on the fink team, ask maintainers to provide debian packages and to certify that they are clean. (I do this informally anyway.) 3. Allow the user finer configuration for source/binary. ------------------------------------------------------------------------ ---- a. If I could select binary-only installation for most packages (eg: KDE) and then over-ride this for some individual packages, my updates would be far more efficient. b. Maybe instead of "stable vs. unstable" we could divide it into "binary and source vs. source only" trees. Make everything that is critical as a dependency and/or popular available in the binary distribution, and permit users of uncommonly used but painful to compile packages (my coot and ccp4 packages come to mind) some sort of option to access binary distributions as well. c. Clarify to maintainers the expectation that functioning packages belong in "stable." Almost everything I maintain is in unstable mainly because I didn't want to be a nuisance. 4. Ditch support for obsolete versions of OS X. ------------------------------------------------------------------ With limited resources, it might make sense to focus only on the current version of OS X packages, or at least phase out support or freeze support for obsolete versions of OS X. If I get a complaint from a user of one of my packages for 10.3, I have no way to deal with it. AFAIK, there is no policy regarding the expectations for package maintainers to maintain their packages on obsolete platforms. 5. Hire someone to keep critical stuff up to date and running smoothly. ------------------------------------------------------------------------ --------------------------- a. Maybe we could get Bill Gates to donate ... b. Given how heavily many scientists who use OS X rely upon fink, I wonder if it might be worth applying to the NSF for some grant support? I made mention of this on the WIKI several months ago. If there is sufficient interest, I would be happy to lead the charge (maybe happy and grant writing shouldn't be used together, but I'd be willing to put in some serious time and effort on this). ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel