At 17:58 Uhr -0400 14.04.2002, David R. Morrison wrote: >I'd like to broaden the discussion a bit, by introducing another class of >.app's which I think we might have in the future: Foo.app which provides >an Aqua interface to some open-source package (which itself depends on >many other packages) that can be installed by Fink. In this case, I >would argue that some kind of interaction with Fink is desirable, because >Foo.app would want to query the Debian database when it is being installed, >and on the other hand, we would want Fink to complain about removing the >dependent packages if Foo.app was still installed. > >I don't know how to solve the problem of users moving a Foo.app around, >but I have an idea about it (which you are welcome to shoot holes in). >Foo.app gets installed with Debian tools, and the installation includes >a file in some specific location in the /sw heierarchy which the user >*won't* move. We use that file as Fink's record that the package has >been installed, and we ask that Foo.app should upon startup, check for >the existence of that file and if it's not present, quit with a warning >to the user to reinstall the Fink package. (The binary which does that >shouldn't be linked to any Fink-installed libraries, of course, so its >some kind of wrapper around the program itself.) On the other hand, >if the user tries to remove the Fink package and the .app itself can't >be found, the user could be given a warning that Foo.app hasn't been >removed but won't function anymore, and that the user ought to find it >and remove it. > >OK, maybe not so elegant, but I hope the point is clear.
Not really. I understand what you explain above. But it doesn't justify packaging the .app in the first place, it only describes an ugly (no offense meant) way to hack around a problem that stems from the fact that we abuse Fink/dpkg for something it wasn't meant to do :-) If I write say a wrapper around wget - well, I will have to check for it's presence anyway, why should I tie myself to Fink ? Please name me some real case scenarios, and why making the .app Fink based there would be an advantage. I don't like discussion this based on purely theoretical setups. >If you guys agree that there is some class of .app's which are appropriate >for Fink, then we can ask whether OroborOSX and FinkCommander qualify. >Neither one is quite as closely linked to Fink as I have described above, >but both would be very useful to Fink users, and perhaps the method I >outlined above could provide a way to make Fink packages for them. I agree that one could use that method above to (rather awkwardly) "package" these with Fink, but I see nothing to be gained by doing so. Max -- ----------------------------------------------- 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
