-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Peter O'Gorman wrote:

Darian Lanx wrote:

| Hello community.

Thanks for posting this, it does however apply more to .apps rather than
.frameworks.

Thank you. Let us focus on .apps then. As I said, this write up was not meant to be complete. What should be done then, so that we can easily integrate .apps into Fink.

| 1.) the Source has to be available.
sre thing, and the fink package has to use that source to build. I really
dislike that some packages download binaries.
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.


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

So doing something lile /sw/Frameworks

and maybe a symlink like /sw/Library/->
Or would you scrap the Library top-Dir all together ?

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

More idea please :)
I know Benjamin (RangerRick) has a 'solution' for issues with Ressource Forks that could arise when packaging the .app


| 5.) A 'native' as well as a 'unix' Application of the same type need to
| be installable at the same time

Well, no, if there are both, then sure, both should be available to be
installed at the same time, but I see no need for a hard and fast rule about it.
No, I can agree. This should not be a rule, but a goal.

- -d

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAG+dCPMoaMn4kKR4RAxUlAKCU2g6LmHy3ibrVPCVbV+QaB9BHKgCgiuRr
k3z4KNwzqlG3XO+QM3nl+YA=
=d5UY
-----END PGP SIGNATURE-----


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

Reply via email to