I agree with Martin that we should accept this as the new policy, but for now confine these packages to the unstable tree to give some time to make sure we don't need to modify the policy further.
Martin: I was probably the one who suggested in the earlier discussion that the symlink for the .app should go in post-install/pre-remove. My reasoning was this: the whole reason for using symlinks rather than directly putting the .app into /Applications/Fink/ is that the user might later move this around, and then dpkg's database would be incorrect (and things might not get removed when they should). So, is it OK for one symlink per .app in the dpkg database to be potentially incorrect? Or should we do this in post-install? (I don't have a firm opinion on it, so I ask the question.) -- Dave Martin Costabel <[EMAIL PROTECTED]> wrote: > Jeff Whitaker wrote: > > > All: I'm working on a new r-base package which will include R built as a > > framework and R.app (in addition to the command line X11 version of R). I > > went back and re-read the thread on .apps in Fink, but it didn't seem like > > there was any consensus on the issue of whether to install symlinks or > > aliases for apps in %p/Applications. My new r-base package now does this: > > > > 1) installs the framework in %pLibrary/Frameworks. > > > > 2) installs the .app in %p/Applications. > > > > 3) puts a symlink to %p/Applications/R.app in /Applications/Fink/R.app > > (in a post-install script). > > > > 4) removes the symlink in a pre-rm script. > > Just one question: What is the advantage of pre/post inst/rem scripts in > comparison with just creating the symlink in the InstallScript? I find > the latter cleaner, because you see the /Applications/Fink/foo.app in a > "dpkg -L" listing. In a later stage, this part could perhaps be done by > fink automatically, with a "Applications: foo.app" field or something > similar. > > > Is this reasonable - or should I hold off on this pending further > > discussion? > > I am in favor of accepting this now. > > > BTW: python and tcltk could be packaged to do this as well. > > I have a tcltk-aqua info file for version 8.5a1 that I will soon put > into my experimental directory. I think we need a couple of working > examples in order to find the points that still need discussing, like > how frameworks fit with the shlibs philosophy, or: Should all .apps be > pulled out into %p/Applications, even if they are by default created > inside the framework (Wish Shell.app in the case of tcltk-aqua). > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
