Re: More an autopackage
Geoffrey Wossum wrote: ... the job right now. For instance, our packages are supposed to have a pre-install script that does a click-through agreement. I've tried to explain that you can tell the package system (rpm, at least) not to run pre-install scripts and therefore it probably wouldn't hold up in court. But anyway, the powers that be want that pre-install script capability, which epm doesn't seem to support. Actually, you could probably steal the script stuff from the portable.c file that shows the license agreement. I wouldn't wait for the response (that would break GUI installers), but at least you can cat out the license agreement to the screen... ... generates the epm list file. It's double work, but eventually autopkg would get support for "native" package systems. Then later autopkg will be able to scan Makefile/Makefile.am/some_file to automatically generate its install info file. We're hoping to extend EPM in v3.0 to support sub-packages and other things so that you can utilize more of the RPM/Debian/PKG/DEPOT/INST capabilities. We also have some beta patches that add AIX support (probably go into 2.4), so the list file approach may give you the best bang for the buck, and you won't have to worry so much about dealing with the subtleties of RPM, etc. FWIW, here is a quick rundown of what we're planning to add in future releases of EPM: 2.3 (to be released this week) - Better init.d script location for RPM distributions (makes them portable to multiple Linux dists) - Better directory and config file support for HP-UX - Variable definition in list files (e.g. "$prefix=/dir"), overridden by env or command-line options. 2.4 and beyond - AIX packager support - Better wildcard support (for directories as well as files) - Pre-install commands - Better config file support for packagers that don't know what a config file is. - Better dependency support (version numbers as well as packages) - Sub-package support (e.g. package and package-devel, or package and package.devel, etc.) - BSD-style install script that builds list files for you. -- __________ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: More an autopackage
Tom Tromey wrote: ... MichaelThe downside is that you have to somehow clear the Michaelexisting list file before doing this, or only do it Michaelonce, so that you have the correct set of files... I don't understand this. Basically, the install-sh hack would append to an existing list file. If you run through the virtual install that creates the list file more than once, then you'll end up with multiple copies of files (EPM does filter this out.) Even worse, tho, is that you might end up with a mix of new and old files in the list files, which EPM won't catch... How does EPM handle the case where there are multiple binary packages in a single source package? Right now you build a single package from a single list file. There is nothing preventing that package from containing multiple programs, but you can't install them separately (i.e. no sub-package support, at least not yet...) -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: More an autopackage
Geoffrey Wossum wrote:
Actually, you could probably steal the script stuff from the
portable.c file that shows the license agreement. I wouldn't wait
for the response (that would break GUI installers), but at least
you can cat out the license agreement to the screen...
But just displaying the license doesn't have any legal force. The
user has to be forced to "click-through". For free software
purposes, this isn't a big deal, but it is for commercial software.
Believe me, I know all about commercial issues, but if you are going
to use the RPM format you can't depend on using the console to
confirm, or even the GUI.
FWIW, the EPM portable format also comes with an InstallShield-
style setup program that shows the license agreement in the window
(the same scripts show the license on the console if installed
without the setup GUI...)
...
As far as sub-packages go, it isn't a big deal to make subpackages
with epm 2.2. You just make a seperate list file for each package.
Right, but that doesn't help when you want a single package with
optional parts, which more closely matches the IRIX, HP-UX, and
Solaris packagers.
...
I had a .in file that configure was macro substituting to get the
same effect.
The advantage with the variable support is that it works around
the ${prefix} that usually ends up in exec_prefix, etc.
...
I assume this requires coorperation with the underlying platform
packager?
Yes. The main issue is to support the version dependencies in the
portable distributions - the RPM, inst, etc. formats can already
be easily extended to support the version numbers since they support
them natively.
--
______
Michael Sweet, Easy Software Products [EMAIL PROTECTED]
Printing Software for UNIX http://www.easysw.com
Re: More an autopackage
"Derek R. Price" wrote: ... I'm still thinking a two stage process is in order: A script that scrapes the Makefile and a meta spec file (since the make process is invoking it this could simply mean it is passed the appropriate data) to create the package manager specific spec file and a package manager front end tool that accepts a uniform set of package manager commands and options and turns them into commands and options for the appropriate package manager and invokes it. ... I'm getting into this discussion a little late, but here are my $0.02. First, see: http://www.easysw.com/epm and specifically: http://www.easysw.com/epm/epm-paper.html "EPM", or the "ESP Package Manager", is a tool that does about 1/2 of what I think you want to do for an autopackage program/script. Essentially what is currently available is a program that reads a common "list" file format, generates a platform-specific "spec" file, strips executables and copies files as needed, and runs the appropriate command to build a platform-specific binary distribution. It also supports a "portable" distribution format that uses shell scripts and tar files to do the dirty work of installing and upgrading software. What it doesn't do (yet) is provide a tool to automate the creation of the list file. Some things we've been playing with: 1. Provide an install-sh like script that appends the installed file(s) or directories to and intermediate list file. This will usually mean that you can wire existing apps' makefiles to install into the list file, which then can be used to build an actual distribution. The downside is that you have to somehow clear the existing list file before doing this, or only do it once, so that you have the correct set of files... 2. Provide some sort of script or tool to scan makefiles, looking at the install targets and somehow figuring out what files are getting installed. This is an ambitious project in itself, and probably isn't worth the trouble. A third option in the context of an autopackage program is to provide "AP" macros that are used to build both install rules in the makefiles and entries in the list file. This at least reduces the amount of duplicate effort required between software packaging files and Makefiles, and if done right would provide all of the necessary information for a variety of systems. -- ______ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: More an autopackage
Pavel Roskin wrote: ... not as root. GNU tar cannot be tricked into hardcoding the ownership different from the actual ones (as far as I know). ... Also, you can't map the filenames/directories, e.g.: filename.c - project-major.minor/filename.c program - /usr/bin/program -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: More an autopackage
Rusty Ballinger wrote: ... (What packaging systems only let you create packages as root, and why do they do that? I know rpm *wants* you to be root, but you don't have to be...) Debian's dpkg needs you to run as root; otherwise the files you install will be owned by your user group. HP-UX's swpackage needs you to run as root if you want to access the files you've packaged; you can open up a "depot" to regular users, but the files are created as root and are readable only by root... -- ______ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
