I can understand that. I think one of the major plus points would be, that your .app is automatically upgraded once the package maintainer packages a new version of that specific software. Especially with Open Source software that is going 'native' I'd see that as a plus point. Maybe this would also encourage application writers to offer info files on their own.
Definitely.
| 2.) The directory Structure should mimic the one given by Apple, | resulting in something similar to: | /sw/Library | /sw/Library/Frameworks | /sw/Library/PrivateFrameworks | /sw/Applications
Yes, this is what people are used to seeing, there really isn't an
alternative, although it seems silly to have a $prefix/Library that is emty
except for the Frameworks dir. I don't see fink ever needing a
PrivateFrameworks dir though.
Right, no PrivateFrameworks, but I still thing we should have /sw/Library just so it's clear that it's part of the Apple hierarchy.
More idea please :)| 3.) Applications should be installed in a hidden directory, a symlink | could be created in /sw/Applications. This symlink could be moved | without confusing the deb packaging engine (Is this correct?)
I really do not think a conclusion was reached here, I like this idea though. It makes it extremely unlikely that the user will remove the original application by accident.
I know Benjamin (RangerRick) has a 'solution' for issues with Ressource Forks that could arise when packaging the .app
I've been thinking about how some of this would work. It's also come up recently on the DarwinPorts list, and the suggestion was to use /Developer/Tools/SplitForks to be able to package up the apps, and then put them back together with /System/Library/CoreServices/FixupResourceForks. Because darwinports doesn't have much control over pre/post install scripts, it'll probably be harder for them to deal with, but the way I see it happening is this:
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
2. Foo.app and Foo.framework are installed to /sw/.Applications and /sw/Library/Frameworks respectively. Only app bundles really need to be worried about too much, it's not likely people will move frameworks around, but if we wanted to we could ghost those too.
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).
Does this seem reasonable?
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
