Darian Lanx:
except for the Frameworks dir. I don't see fink ever needing a
PrivateFrameworks dir though.
Right, no PrivateFrameworks,
Mostly agreed. PrivateFrameworks is for non-public frameworks, and open source frameworks are pretty much public by definition.
but I still thing we should have
/sw/Library just so it's clear that it's part of the Apple hierarchy.
Agreed.
I know Benjamin (RangerRick) has a 'solution' for issues with Ressource
Forks that could arise when packaging the .app
1. Add a new field like JarFiles: BundleFiles
A package that makes an app bundle (or framework for that matter) would
have:
Package: foo
BundleFiles: Foo.app Foo.framework
I'm not sure if it's really BUNDLES that we want to treat specially here, rather than just applications. I could see where a special treatment for apps would be useful but frameworks should be pretty straightforward. Besides, there are other types of bundles, each of which presumably would call for different treatment. I would suggest just marking applications and installing other bundles manually.
2. Foo.app and Foo.framework are installed to /sw/.Applications and
/sw/Library/Frameworks respectively.
I'm somewhat uncomfortable with .Applications, as that would make a potentially large directory invisible from the Finder. I agree that our objective here is to make the directory "invisible" so users don't mess with the contents, but I feel that this could be achieved through other naming means than making the directory invisible. How about /sw/lib/applications ? (I was going to suggest /sw/libexec/applications, but it turns out we don't have /sw/libexec). Fink users should be sufficiently trained not to mess with /sw/lib.
3. Before actually building the deb package, we run SplitForks on the
destroot tree.
4. Fink adds calling FixupResourceForks to the PostInstall of all
packages (preferably with a list of files, kind of like the prebinding
stuff, so it's not too taxing on the system; it has to be done
per-package in case another package depends on, say, the python
framework to be able to build).
Interesting idea, but is it actually worth to support resource forks in MacOS X? I've never used any in my X apps, but then, I've never written a Carbon app on X either. My understanding was that nowadays, any app can be packaged without using resource forks.
Matthias
