Re: [Bug-gnubg] Package for MacOS

[Michael Petch]

On 5/9/08 11:44 PM, "Achim Mueller" <address@hidden> 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