On Sunday, Jan 12, 2003, at 07:49 US/Eastern, Max Horn wrote:
Which is not a problem!At 20:14 Uhr -0500 11.01.2003, Bill Bumgarner wrote:On Wednesday, Jan 8, 2003, at 14:33 US/Eastern, [EMAIL PROTECTED] wrote:That's not helpful, though, the location is not the problem. The problem is that any locations for Fink installed stuff have to be fixed. By the fundamental prinicple of how Fink and dpkg work.
I know this has gone around before... but, to flog a dead horse a bit more because this has really started to be a serious hindrance to Fink in the eyes of many people I know.We don't generally accept bundled .apps in fink, because they can be moved by the user, and also to keep fink focused.
1) There is no reason for Fink to install apps in /Applications. Applications work fine anywhere on the disk. So do frameworks.
If the apps are installed in /sw/Applications/, they will work fine and will be under the Fink tree. Problem solved.
He replied based on false assumptions and, unfortunately, I lost his message.2) Apps can't be moved any more readily than, say, /sw/bin/python or /sw/share/doc/apache. Same goes for frameworks.
Benjamin already replied to this, so I won't do it again.
Bottom line: If any application is installed in a proper, network computing style, fashion, then no user should be able to move it or rename it without superuser privileges. Exactly like no regular user can move /sw/bin/python or other items in the /sw tree.
That /Applications is editable by the default user on OS X is a bug resulting from the need to support a naive world view coming from legacy Mac users, IMO.
In any case, there is no need to install in /Applications.
fink update-all3) More and more Unix related tools have native Aqua ports available. tk and wx immediately come to mind. Film-gimp on the applications front. With PyObjC, CamelBones, and other bridge type technologies coming along, I'm sure there will be more. Many of these require or, at the least, are designed to use an app wrapper.If something is a proper mac application, there is no reason in my eyes why one would want to install it with Fink. E.g. Film-gimp (though I never tested it, I am just assuming now it is so).
That, in and of itself, would save tons and tons of time over having to download and individually install each application with every update.
Especially for apps like film-gimp and other open source OS X apps that are updated fairly regularly.
With suites that include frameworks, it also allows dependencies between the frameworks and other apps that use the frameworks.
And, of course, frameworks do not need to be installed in /Library/Frameworks anymore than apps.
Stuff like "native" tcl/tk can usually be supported by system-* packages.Again:
fink update-all
In managing a network computing environment with a dozen or so hosts or even in managing my own home net, I constantly run across situations where I forgot to walk to each machine and install some stupid package.
But not fink. With fink, an occasional 'fink update-all' keeps everything up to date and in sync.
Fink is an incredible administrative tool that is currently hobbled [and growing more hobbled as time passes] because it does not package tools which are becoming more and more prevalent on the platform.
I believe that the technical and logical reasons are flawed... Apps and Frameworks can be installed by Fink in a fashion that does not pose any more of a risk of the user screwing with the app-- moving or renaming it-- than any of the other resources installed by Fink.I don't see how supporting the *native* version of something like tk or wx would be a loss of focus for Fink. If anything, it tightens the focus -- it continues the fine tradition of Fink providing highly tuned, ultra-compatible, builds of Unix/Open Source projects to the OS X community.I didn't bring up the "focus" part, and I think it's realy only tangential to this discussion. It's no "focus" thingy that makes me oppose including all sorts of .apps, it's techincal and logical reasons, see above.
Said like a developer....Besides-- it seems really sad that FinkCommander isn't a standard part of the Fink installation....<shrug> To you it may be so. I never used it (besides trying it out), and I never missed it. I realize some people like it a lot, but others (like me couldn't care less). It's easy enough to install it if you want it.
To a lot of people new to Fink, Fink Commander is the *only* way that Fink becomes remotely comprehensible.
I don't use it either, but I know of a bunch of people who care a lot less about Unix than I do that DO use FinkCommander.
b.bum
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
