site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Thread-index: Acc/2kwhVDh/JOMgTl6/DW4Al/gp+QAAID9w 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=hp.com@lists.apple.com [mailto:installer-dev-bounces+fred.handloser=hp.com@lists.apple.com] On Behalf Of John Clyne Sent: Wednesday, January 24, 2007 9:08 AM To: installer-dev@lists.apple.com 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) clyne@ucar.edu _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/fred.handloser%40hp .com This email sent to fred.handloser@hp.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com