David R. Morrison wrote:
Dear Fink developers,
We agreed some time ago to allow Application bundle packages in Fink,
and we now have a few of them. There is an AppBundles declaration
available in .info files (although I understand from some previous email
traffic that it does not really serve people's needs -- that is
something we should work on).
The AppBundles declaration has one problem (which I remember complaining
about a long time ago): It is not documented what is its implicit
prefix. Is it %i as for the Files field or %b as for the DocFiles field
(both of which are not very clearly documented in this respect either)?
I think it is %b, which is probably not the most useful, apps being
complete only after installation, in general. In any case, trying one
way or the other, I never managed to use it in my packages.
I'm writing today to try to clarify where such packages should install
their files. We need to update our docs about the file heierarchy to
reflect this, as well as to modify 'fink validate' to accept files in
appropriate locations.
What I believe we agreed to was that Application bundle packages would
install their application bundles into /sw/Applications and that the
postinstall script would then create a symlink from this into
/Applications. This is in fact what the AppBundles declaration is meant
to accomplish. (The reasoning here was that when it comes time to
uninstall, if the symlink has been moved we'll just abandon the attempt
to uninstall it, and we can be more confident that things in
/sw/Applications did not move than that things in /Applications did not
move.)
I thought the symlink should go into /Applications/Fink/, not into
/Applications/ directly. At least that's where the packages I have seen
(or made myself) put it. The AppBundles documentation says so, too.
I have packages that make the symlink in the InstallScript, not in the
PostInstScript. My argument was that I prefer to see in the file list
what the package installs. OTOH I received one complaint from a guy who
had /Applications as a symlink, which then was duly removed by
uninstalling the package in question. So I guess I won't insist on this,
and I'll accept that requiring that the symlink should be made in the
PostInstScript is OK, and I will update my packages correspondingly in
the near future.
The question is, though, what to do about /Library and /Frameworks
installation paths. A variety of things are currently being used in the
small handful of Fink packages which install bundles. We have
/sw/Library/Frameworks
/sw/Library/Python
represented in current packages.
So one possible policy would be to say that application bundles should
go in /sw/Applications, with symlinks in postinstall (preferably
generated by the AppBundles declaration), and that any supporting
material should go into /sw/Library, with the layout one would normally
expect in an OS X Library directory.
I agree, but the formulation "any supporting material" sounds
restrictive, it is too general. The dylibs used by an app can very well
be the standard Fink dylibs in /sw/lib. I don't think we would want to
force the use of /sw/Library. We should use it only when the package
absolutely wants to build frameworks, as a replacement for /Library.
I would say even the mixture of both is OK, as it is used by the
aquaterm package which has a /sw/lib/libaquaterm.1.0.0.dylib with an
install_name of
/sw/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm. This
ensures backward compatibility and allows "dual use", by linking either
with "-L/sw/lib -laquaterm" or with "-F/sw/Library -framework AquaTerm".
For /sw/Library/Python, there is probably only the snappea-nox package
using it, but it could be a more general repository for python modules
using the system python. It seemed the most natural place to use for
this. I don't remember if /sw/lib/python2.3/site-packages/ (with or
without installing Fink's python23) would have worked or not. The
PYTHONPATH env variable allows a lot of flexibility here.
I would also love to see Fink packages that use the system Tcl/Tk
frameworks, but I am not sure where they should install things and how
this would work.
--
Martin
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
