I think it is of interest for more people, so instead of continuing this on a tracker item <http://sourceforge.net/tracker/?func=detail&atid=414256&aid=543612&group_id=17203> I post my biiig reply to fink-devel:
Martin, 1) I didn't say it is the same as OroborOSX, i just mentioned it as another example of a rejected package with similiar reasons. 2) I think it's a bit cheeky of you to presume I was "rejecting" FinkCommander, since it's not true. Or to claim that we/I never even looked at it (I did). I am *NOT* rejecting it. Still I don't think you have the right to demand from me or anybody else to "refine" it, it's a personal decision whether one likes/has the time to contribute. So, maybe consider what you wrote. I found it quite embarrassing and a bit insulting. 3) That FC doesn't come as a precompiled binary is indeed bad, and is something the people working on it should change. Put up a precompiled binary. The lack of that is probably the reason that not so many people have looked at it. Make a diskimage; if you like I can help you to automate this. If people can click to download it, which mounts the image, and then have to double click the icon, they will use it. Also, I haven't seen "ads" for it on fink-users/fink-beginners. I think *that* is the reason that it's not widely used. Another possible reason might be that the interest is not as great as you think, I dunno. Remember: making a Fink package is not the only way to provide binaries for stuff. Basially no OS X app does it, and many do very well anyway. 4) Uhm, yemaybeah, a FC package would open it for a wider beta testing (shipping a precompiled binary on a diskimage would do, too, though). But Fink is not meant for beta testing software. We usually package well-tested stable software. There are exceptions of course, but still this is IMO a weak argument. 5) I don't see how the evolution of FC is affected by it being a Fink package or not. It's a bit easier to update, but that's about all. But checkout this: http://www.cocoadevcentral.com/tutorials/showpage.php?show=00000047.php - you could easily use this for FC to have it check for newer versions, and give the user a button to start the download/mount the diskimage in one way. Then they only have to drag the old into the trash and the new onto the desktop. Update done. That's how a GUI app should handle this, I believe. 6) Yes, there are other packages installing .app files. Let's look at them: - AquaTerm.app is normally never used directly but as an auxillary app - Emacs.app - I never liked this one. There is one defense for it, though, it can't be moved anyway (if you move it, it breaks - at least it used to be this way). - XDarwin.app is a special case, and that was discussed many times in the past. And it can be obtained seperatly, but again it''s a special case. I think you can't seriously pretend you don't understand this. I won't let myself convince to do it only because others have done it. Other people steal, that doesn't mean I have to. Now don't get me wrong, neither am I comparing FC to stealing (would be a rather pointless comparions <g>), nor am I saying that FC never will be packaged. I just say that this point is no reason at all. You can approach this from the "special case" side, but don't come to me with "oh but XYZ does it, too", I am not convinced by such "reasoning". 7) You sure are not the first to have this idea. This shows that other people have an interest in this. But the exact same thing is the case for OroborOSX, for example. And for a ton of other things. We have rejected things that several people asked for in the past. Like packaging perl 5.6.1 (or newer), or switching from Debian to RPM, or packaging OrborOSX, or packaging open source Cocoa apps in general, or packaging commercial binary-only stuff, etc. etc. That doesn'T mean these things have their valid points, but rather that they are not fit for Fink! 8) Finally, it doesn't have to be in the FInk distro to be Fink-packaged. It's easy enough to ship a info file with instructions (or even an installer) to put it into the local tree (or a future contrib tree). Heck, you could even put it into a specially prepared dir with a CVS dir in it, so that "fink selfupdate-cvs" would get new versions of the .info file I firmly believe that one thing that makes Fink strong is its focus on various key properties. Dilluting them is not going to help us. One of these properties is that we stick as much as sanely possible in /sw, and we package *unix* applications (except for a few auxillary Cocoa/Carbon apps, like AquaTerm and XDarwin). That said, I didn't reject the FC package yet, did I? I explicitly left the tracker item open and said that this should be discussed. At least be fair enough to grant me that before condemning me Now I'd like to hear what others say. Why is it so important that we have a FinkCommand package? Why is a GUI so important? Do people that use stuff like Fink really have to have a GUI, for things that they have from the command line in the end? I know there are maybe a few cases, but is the majority of Fink users really going to need it? Why is it so much better to have this a Fink package instead of a seperate download? Please, nobody presume what my position is, for you are not in my head so you can't know it. I do have a position, but I seriously want to evaluate this matter thoroughly. I try to stay open minded. Please try to do the same. Max At 6:41 Uhr -0700 14.04.2002, [EMAIL PROTECTED] wrote: >Package Submissions item #543612, was opened at 2002-04-14 09:29 >You can respond by visiting: >http://sourceforge.net/tracker/?func=detail&atid=414256&aid=543612&group_id=17203 > >Category: None >Group: None >Status: Open >Resolution: None >Priority: 5 >Submitted By: Steven J. Burr (sburrious) >Assigned to: Nobody/Anonymous (nobody) >Summary: FinkCommander package > >Initial Comment: >This fink package will install FinkCommander in >/sw/Applications (or the equivalent). Martin >Costabel did all the work on this. I just made a >couple of minor additions, but I will be happy to >maintain it in the future. > >---------------------------------------------------------------------- > >Comment By: Martin Costabel (costabel) >Date: 2002-04-14 15:41 > >Message: >Logged In: YES >user_id=60552 > >Max, I strongly disagree with you here for several reasons: > >1. You can't compare FinkCommander with OroborOSX. The latter >has nothing to do with Fink, it can be used by anyone who >installs XFree86. FinkCommander is useless without Fink, and >it adds a valuable GUI to Fink. It would be a good thing if >the Fink developers contributed to the refinement and >completion of this GUI instead of rejecting it without >looking. >2. So far, FinkCommander did not come as a precompiled binary >ready to install. It comes as a source tarball and you had to >run ProjectBuilder to compile it, which is probably a reason >why not too many people have looked at it. Using "fink >install finkcommander" should make it (for fink users and >developers) easier to install and open it up to a wider >public for testing. For the evolution of FinkCommander, it >would be a good thing if it could participate in Fink's >automatic updating system. >3. There are other packages that install into /sw/ >Applications: AquaTerm.app (installed by gnuplot) and >Emacs.app (installed by emacs-carbon). FinkCommander has IMHO >more right to live in /sw/Applications than these. And there >is XDarwin.app, of course, which installs even into / >Applications and which really can be easily obtained as a >precompiled OSX application from several sources. >Nevertheless it is also installed via a Fink package. >4. Although it was me who proposed to Steven to submit a >finkcommander info file, I am not the first to have this >idea. It came up in the recent thread "Fink CD" on fink- >devel, see >http://www.geocrawler.com/lists/3/SourceForge/11114/25/ >8351076/ > >So if you are seriously thinking about killing this package, >I ask that there should first be another discussion on fink- >devel. > > >---------------------------------------------------------------------- > >Comment By: Max Horn (fingolfin) >Date: 2002-04-14 14:10 > >Message: >Logged In: YES >user_id=12935 > >Personally, I'd reject this package. Fink was never >meant to package "native" OS X GUI applications, for >various reasons (and this has been discussed often >enough). I see your point that FinkCommander is Fink >related, but I still don't think it should be packaged; just >as I am opposed to packaging OroborOSX. > >1) It's an OS X application, hence getting and installing >it should already be trivial >2) It's an OS X application, so you users can and >should be allowed to move it around at will. But that >breaks the packagaging system of Fink, it can't keep >track of the files this way > >There are more issues, but I think these two alone are >sufficient already. I don't see much to gain by having it >as a package either. Mind you, I am not at all implying >with this FinkCommander wasn't useful or anything. It >should just not be packaged as Fink package. > >I am not closing this immediatly since i want to give >others the chance to comment first. > >---------------------------------------------------------------------- > >You can respond by visiting: >http://sourceforge.net/tracker/?func=detail&atid=414256&aid=543612&group_id=17203 -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
