On Sunday, April 14, 2002, at 07:17 PM, Max Horn wrote:

> 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.

I know several open source apps that are distributed on sourceforge, and 
the source is updated much more frequently than the binaries.  Opening 
the project from within projectbuilder is a pain, especially when trying 
to install it.  I'm not saying we need to do this for every Foo.app out 
there, but I have seen a few where it might make sense.  Also, this 
method could be used for XDarwin.app to keep it within the fink tree.  
Maybe even a similar thing for XFree86.

I really think that some applications should be packaged with Fink, and 
that there is a better way to do it. The fink package would install the 
program in Fink's controlled directory (Maybe %p/bin/Applications, 
%p/Applications, or %p/share/Applications?) and the installscript (Or 
maybe even a special tag 'Application: Foo') would do several things

1) Check for an existing /Applications/Foo.app file/directory
2) If it exists, and is a symlink to %p/appdirectory/Foo.app then leave 
it alone
3) If it exists, but is a symlink to somewhere else, ask the user what 
they want to do (Replace or Ignore)
4) If it exists, and is not a symlink, report an error and leave it 
alone, but continue with installation.

Then the user could move the symlink to wherever they wanted, and it 
would always point to %p/appdir/Foo.app.  If the package was upgraded 
and the symlink was in place, then it would be left alone and point to 
the same app  If the package was upgraded and the symlink was moved, a 
new one would get created but the old would still work.

My idea for XFree86 is:

Installscript creates a directory %p/X11R6 or something like that, and 
(using the same overwrite check as currently used) places a symlink at 
/usr/X11R6 to it.  Then the X11 tree could be kept within a UFS 
partition (case-sensitivity), and everything else would still work.  As 
an added bonus, that would cause dpkg to remove the /usr/X11R6 symlink 
whenever xfree86-server/rootless was removed (Even if other files, 
fonts, junk, etc. were still hanging out in %p/X11R6)

Just a few thoughts,


_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to