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

Reply via email to