When I mentioned fink, I was never thinking of replacing the binary installer, rather just making it easier for the people not afraid to click a compile button to have the latest version compiled from source. For instance, the latest version of aquaterm does have a cursor ... and is part of fink! The idea would be for it to be trivial for someone who has fink installed to graduate to the latest version. As I am hacking around anyway trying to get things to work in fink, I thought it would be nice if someone else could easily update their systems more easily. It is possible incidentally to do binary installs using Fink. The idea is just to make it trivial for someone to install the latest version without worrying about the details that someone else has already worried about. Actually I like the sound of what Matt was describing, but I don't grasp all of the details. One of the largest benefits of fink (and I assume Debian is the same idea) is that Fink keeps track of dependencies and can offer to upgrade the dependent packages if necessary. How would this work with the binary installer bit? I assume the basic idea is that the binary installer would install a complete working package and that fink could offer to upgrade that package. This would seem to conflict (or at least potentially conflict) with the package management feature of fink. In any case the idea would not be to replace the binary installer for those who don't want to bother with the hassle of compiling things, but for those who are willing but just don't know enough about the process to do it themselves to get the latest source code release running. I believe currently, using my installation of horae, ifeffit and friends, Bruce's script works "out of the box". I have installed horae and ifeffit on a friend's machine which works nicely using the fink installed packages (but not using fink itself for the installation yet). On my own machine, I have upgraded to the latest version of perl, etc. and things are a little more complicated (but not much). I was just curious to see if anyone else would be interested in a fink based installation (with all of its pitfalls and warts) as in principle it would be only a small amount of extra work to take what I am doing to keep my horae updated and pass it along to others. On the other hand, if there is not interest, there is no point. If there is a hybrid solution like the one Matt mentioned that would be optimal it seems to me (more thinking/discussion required). Do try the latest version of aquaterm though, it is nice to have things resize on demand! Paul On 2004/04/20, at 6:45, Carlo U. Segre wrote:
I can see both sides. It is important to have ease of installation so that the programs can be disseminated to more users. This will help the development process. That being said, it is important to have a committed group to keep up to date with the sources so that everyone is talking about the same versions and can benefit from the latest improvements.
I suspect taht once the horae software reaches an advanced version number, issues like this will become less important as stability in the basic code is reached.
Carlo
On Mon, 19 Apr 2004, Bruce Ravel wrote:
On Monday 19 April 2004 05:11 pm, Jeff Terry wrote:
It's also so unmac-like to force users to compile from scratch.
I acknowledge that this was said with tongue in cheek. Still, I cannot come up with the right language to express how extremely little being "mac-like" matters to me.
That said, I think that I neglected to mention a few of the underlying assumptions of my last posting.
Assumption #1: My codes have bugs. Some of them get in the way of getting work done.
Assumption #2: I am constantly working on fixing the problems in my codes. That is a good thing.
Assumption #3: People would prefer to avail themselves of code that fixes serious bugs in the timeliest manner possible because it is better to use code with fewer bugs than code with more bugs.
I maintain the source code package continuously. Thus, the fastest way to disseminate bug fixes to end users is in the form of source code. This has the additional advantage of not requiring the additional and probably time consuming step of building and verifying a binary package.
But I am not the sort to pass judgement on a culture that I am not a part of. If doing things the "Macintosh way" takes priority over doing anaylsis with code which has fewer bugs, than that is just fine with me.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Dr. Paul Fons Senior Researcher National Institute for Advanced Industrial Science & Technology METI Center for Applied Near-Field Optics Research (CANFOR) AIST Central 4, Higashi 1-1-1 Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636 fax. +81-298-61-2939 email: paul-fons@aist.go.jp The lines below are in a Japanese font 〒３０５−８５６８ 茨城県つくば市東１−１−1 つくば中央第４ 近接場光応用工学センター ポール・フォンス主任研究官