RE: conventions for command line utils
RE: conventions for command line utils
- Subject: RE: conventions for command line utils
- From: "Handloser, Fred (LightScribe)" <email@hidden>
- Date: Wed, 24 Jan 2007 11:27:05 -0600
- Thread-topic: conventions for command line utils
Our group builds a few install packages that target Linux and Mac OSX.
We have been using a tool named epm that reads a manifest and builds a
"native" package for the target machine. This allows us to maintain
one manifest while building a ".pkg" package for the Mac and a ".rpm"
and a ".deb" package for our Linux targets.
We do have some slight differences in the installed footprint, but epm
allows us to use and include mechanism in the manifest to include the
customized parts based on machine on whiche we are building our package.
This may not be a good solution for everyone, but it has worked well for
us. Epm also comes with source code so you can (and probably will need
to) modify bits of it to get the package to be built the way you want it
to build. For example, I had to add "rootvolumeonly" as a directive
to the osx.c epm source so I could add the "%rootvolumeonly true"
directive to our manifest to generate the
"<key>IFPkgFlagRootVolumeOnly</key> <true/>" entry in the Info.plist
file that is built during are automated builds.
Take a look at http://www.easysw.com/epm/faq.php?all if you are
intereseted. It is free.
-----Original Message-----
From: installer-dev-bounces+fred.handloser=email@hidden
[mailto:installer-dev-bounces+fred.handloser=email@hidden] On
Behalf Of John Clyne
Sent: Wednesday, January 24, 2007 9:08 AM
To: email@hidden
Subject: conventions for command line utils
Hi,
I have some questions re installation conventions used in the Mac world
when porting multi-component applications from other unices. I have an
app that consists of a GUI, several command line utilities, shared
libraries depended upon by both the GUI and CLUs, header files, doc,
etc. I'd like to provide the package via an installer that is familiar
to Mac users, and minimizes setup required prior to using the tools. In
Linux, for example, the installer would be a shell script allowing the
admin to specify a target installation directory. Setup would consist of
yet another shell script that users could source to configure execution
paths, shared library paths, etc.
The notion of Mac Bundles, with their drag-and-drop installation, is
obviously a much more elegant way to handle software distribution.
However, it's not clear that Bundles are at all appropriate for packages
composed of multiple CLUs with shared library dependencies:
how would one resolve the shared library paths?
So I guess my questions boil down to
1. Are there any best practices for CLU installation? Put them in a
well-known location (e.g. /usr/local/{bin,lib,include}) where they will
hopefully automatically appear on the appropriate search paths, or
provide the flexibility to install anywhere and use some other mechanism
to resolve setup issues (paths)?
2. What tools are recommended for building an installer for a multi-
component application such as i'm describing?
Thanks for any guidance!
cheers
John Clyne
National Center for Atmospheric Research
303.497.1236 (w), 303.809.1922 (c)
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden