On 5/9/08 11:44 PM, "Achim Mueller" <[EMAIL PROTECTED]> wrote:
> I'm planning to make packages for MacOS 10.5 now. This is easier said than done - depending on how you intend to "Package" things. Unlike most distributions, MAC OSX and DarwinPorts - All the library paths are hard coded. Yeppers! You can't just take all the libs and put them in the gnubg directory, or put them in the standard MAC lib dirs and hope the dynamic runtime linker finds them. If one was using Fink (which has issues with 10.5) there is another option. Before I go any further. I'll ask you how you were considering packaging things (A dmg with Just an .App in it, a DMG with an install program etc). Were you intending to package up the entire /opt directory? Where do users have to "place the packages"? Is GnuBG in /opt or installed elsewhere. It is a good idea to have a package that preferably includes the libraries since there is no guarantee the user may have DarwinPorts installed. Unfortunately - some people may already have DarwinPorts on their system. If files are placed overtop of existing files the user may end up with other DarwinPorts software that may not work. Back in the old days I was using Fink, someone created a GnuBG DMG, and a secondary package (With the library components, etc components bin components) that had to be copied into the /sw directory (Fink used /sw instead of /opt). Unfortunately, I extracted the files on top of my existing fink system. Gnubg worked but because I was using dveelopment libraries with certain types of features enabled - I screwed up other Fink apps by clobbering them with what the GnuBG MAC maintainer gave out. What is really preferable is a single DMG file that can opened, and the APP placed (dragged) into any folder (Applications for example) where you just run it (And the single package would contain all required libraries, etc files, etc for GnuBg to function). This is possible, and I have done it with Darwin Ports but it requires doing BINARY replacement of the /opt paths and make them all relative paths. And by relative I mean the etc, lib, bin directories would be inside the GnuBg.app and not in /opt/lib /opt/usr /opt/bin etc. Its probably a good idea to let me know specifically what you were considering and how you were going to package things so that I can be more specific. This response will be vague until I have a better idea of what you are doing. Mike _______________________________________________ Bug-gnubg mailing list Bug-gnubg@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnubg
