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
On Mon, Jan 22, 2001 at 09:49:04PM -0500, Michael Sweet wrote: 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. Paraphrasing Rusty Ballinger, dpkg "wants" you to be root, but you can fake it. I regularly build packages as a non-privileged user. The LD_PRELOAD tricks that "fakeroot" plays will result in a tarfile full of "root-owned" files. -Steve
Re: More an autopackage
"Michael" == Michael Sweet [EMAIL PROTECTED] writes: Michael http://www.easysw.com/epm I haven't tried this, but I read through the web site, and it definitely looks like what I'd like out of an `autopackage'. Michael 1. Provide an install-sh like script that appends the Michael installed file(s) or directories to and intermediate list Michael file. This will usually mean that you can wire existing Michael apps' makefiles to install into the list file, which then Michael can be used to build an actual distribution. This is an attractive idea, but it doesn't work if you also want to extract the post/pre-install/uninstall commands automatically. And you definitely do want to do this because sometimes these are hairy scripts generated by automake itself. One approach, which ought to work, would be to use the install-sh hack and then scan each generated Makefile looking for the magic *_INSTALL variable instance. Then you could have a small script to extract these fragments automatically. This is a bit ugly, but it ought to work ok, at least with automake-generated Makefiles (the only ones I care about :-). 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. How does EPM handle the case where there are multiple binary packages in a single source package? Michael 2. Provide some sort of script or tool to scan makefiles, Michael looking at the install targets and somehow figuring out Michael what files are getting installed. This is an ambitious Michael project in itself, and probably isn't worth the trouble. I agree. This could be very hard. Take a look at the ugly Makefiles generated by automake... Michael A third option in the context of an autopackage program is to Michael provide "AP" macros that are used to build both install rules Michael in the makefiles and entries in the list file. This would work but would probably require extensive work on automake. That makes it unlikely. Anyway, I'm really glad to find out about EPM. I had never heard of it until this discussion. I'm definitely interested in enhancing automake to make EPM's job easier, if that is possible. Tom
Re: More an autopackage
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. 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. 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. autopkg could just generate seperate list files, and epm could concentrate on handling the details of the packager. This doesn't help people who want to use epm in isolation. But people using epm in isolation have to manually write list files anyway. - Variable definition in list files (e.g. "$prefix=/dir"), overridden by env or command-line options. I had a .in file that configure was macro substituting to get the same effect. - Better dependency support (version numbers as well as packages) I assume this requires coorperation with the underlying platform packager? --- Geoffrey Wossum [EMAIL PROTECTED]
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
On Jan 22, 2001, Michael Sweet [EMAIL PROTECTED] wrote:
What it doesn't do (yet) is provide a tool to automate the creation
of the list file.
make install DESTDIR=/tmp/install
find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,'
rm -rf /tmp/install
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
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
"Michael" == Michael Sweet [EMAIL PROTECTED] writes: Alexandre Oliva wrote: On Jan 22, 2001, Michael Sweet [EMAIL PROTECTED] wrote: What it doesn't do (yet) is provide a tool to automate the creation of the list file. make install DESTDIR=/tmp/install find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,' rm -rf /tmp/install This is exactly what I had in mind in combination with package specific install (i.e. make install-package-foo, make install-package-foolib etc. This isn't an improvement over the existing RPM an dpkg paradigm; installing all files to a temporary directory wastes disk space (please, disk space is cheap but how many of us have unlimited space) and precious build/development time. You normally *have* to package only installed binaries, especially with libtool libraries. Ganesan -- R. Ganesan ([EMAIL PROTECTED]) | Ph: 91-80-5721856 Ext: 2149 Novell India Development Center. | #include std_disclaimer.h
RE: More an autopackage
-Original Message- From: Derek R. Price [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 10:36 PM To: [EMAIL PROTECTED] Cc: Geoffrey Wossum; [EMAIL PROTECTED] Subject: Re: More an autopackage Tom Tromey wrote: Unfortunately, I don't think it is that easy. First, Makefile.am contents can be conditional on the particular configuration. That is why you really want to deal with the post-configuration package (using `make') and not Makefile.am. Second, the more complex post-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Good point, but the general design I pointed out should still hold. Only the generated Makefile would be the source for the data needed for spec file generation rather than the Makefile.am, whether that's passed in or scanned. The pre/post install hair should be scannable from the Makefile as well, whether that's for a shared library or info. The spec file source would want room for install hooks as well, still. That way instructions for, say, taking a daemon down and up again could be inserted before automake acquires a daemon target. I think this need to depend on the configure-generated Makefile will have a very constraining effect on the implementation language: this precludes using ANYTHING that's not installed standard on any of the expected target OSes... That's exactly why configure generates sh-scripts and why libtool IS a shell script. You can use GNU m4 or PERL in autoconf and automake, as these are maintainer-only tools. If autopackage is a package-installer tool (i.e. a native package front-end) the choice of implementation language is almost restricted to "/bin/sh" or "/bin/sh" and probably "/bin/sh" :-) Just a thought, hoping to be wrong, Bernard Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: More an autopackage
I think this need to depend on the configure-generated Makefile will have a very constraining effect on the implementation language: this precludes using ANYTHING that's not installed standard on any of the expected target OSes... That's exactly why configure generates sh-scripts and why libtool IS a shell script. The user will only need autopkg (and Python/Perl/whatever) if they want to build packages. They do not need autopkg and its implementation language if they don't want to do this. You can use GNU m4 or PERL in autoconf and automake, as these are maintainer-only tools. If autopackage is a package-installer tool (i.e. a native package front-end) the choice of implementation language is almost restricted to "/bin/sh" or "/bin/sh" and probably "/bin/sh" :-) I would imagine that 95% of the people using autopkg would be package maintainers. These people probably would install any language required if it made their job as package maintainers easier. There will be some people who want to compile their own stuff, but also want features a packaging system provides, like dependency tracking and uninstall. These people would probably also be willing to install Python or Perl to get the features. --- Geoffrey Wossum [EMAIL PROTECTED]
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
Hi, Pavel Roskin [EMAIL PROTECTED] writes: [snip] This module may be very valuable for you if you want to create packages not as root. GNU tar cannot be tricked into hardcoding the ownership different from the actual ones (as far as I know). You can use 'fakeroot' (now called 'libtricks' I think) from Debian. It is essentially an LD_PRELOAD that overrides getuid/open etc. and makes a process think that it's executing as root. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
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
Re: More an autopackage
Harlan Stenn wrote: Are there several issues here? The package maintainer has the package to worry about. Aha! Here's the crossed wire. What I was envisioning was a package tool designed such that most platforms wouldn't _need_ devoted package maintainers. A single package maintainer using Autopackage could conceivably do all their testing on a single platform once Autopackage and the associated Automake support was finished and debugged (heh). Then a user could download a source distrobution and blindly build and/or install the platform specific package they require. An aim worth working in Bourne shell for, I'd think. Someone who wished to make such a built package available for download and do any other value add they desired (previously a package maintainer), could still do so using this tool. I expect those sort of people would still have work, but hopefully it wouldn't be more than tweaking the packages or the AP tool itself and more time could be devoted to real development. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes". I will not call my teacher "Hot Cakes"... - Bart Simpson on chalkboard, _The Simpsons_
Re: More an autopackage
"Derek" == Derek R Price [EMAIL PROTECTED] writes: Due to security concerns, you're obviously never going to be able to install files owned by root without root privledges, but are you really telling me that these systems require you to _build_ packages as root? Yes, this is normally the case because file ownerships have to be root. If so, how hard would it be to tweak the output files? ( sed s/filename:dprice:dprice/filename:root:root/ package newpackage ) That will mess the checksums, so it's unlikely to work. Ganesan -- R. Ganesan ([EMAIL PROTECTED]) | Ph: 91-80-5721856 Ext: 2149 Novell India Development Center. | #include std_disclaimer.h
Re: More an autopackage
Are there several issues here? The package maintainer has the package to worry about. Aha! Here's the crossed wire. What I was envisioning was a package tool designed such that most platforms wouldn't _need_ devoted package maintainers . We're using different language. For example, Dave Mills and I maintain the NTP package. I do all of the auto* work, he does the guts. We'd be thrilled to have something that would produce suitable Stuff so folks who want to build RPMs could do so, and ditto for various other packaging formats. However, Dave and I are not going to have access to all of these systems, so we'd be happy to let Somebody Else ship us patches to for the ABC packaging system used by the XYZ OS. And when I, as the admin of an HP-UX box wants to do a "depot" install using my localized paradigm for package installs, it would be Swell if autopackage accomodated this and wiggled various "configure" options accordingly. For example, I'd often like to default "prefix" to /usr/local/pkg/@PACKAGE@/@VERSION@-@MyLocalConfigRevisionLevel@ (where that last bit starts with the letter "a" and goes up every time I install a different copy, where I decide what "different" means). When I build the package, I would also want DESTDIR set so I could easily package the bundle for other hairy things. H
Re: More an autopackage
I think "layers" of config.site would be useful for parts of autopackage. There are other a number of packages out there that attempt to solve this problem in different ways, with varying degrees of success. One set of extremes is the GNU stow project v. the Modules project. Lately I'm playing with ark.sourceforge.net, which seems to do a nice job of melding a lot of the issues well, and taking a larger view approach. H
Re: More an autopackage
Automake can't create all of the spec file. It doesn't have enough information. And, adding the information to Makefile.am does not make sense (because it is global to a package, which Makefile.am really isn't). Also, generating a list of files is not enough. You also need pre- and post- install and uninstall commands. One way to get these is the *_INSTALL variables, which I talked about earlier. I was thinking about this, and I considered another possibility. autopkg would scan the Makefile.am to build a basic specfile, which the developer could then add pre/post install scripts and so forth. This would be analogous to autoscan producing a basic configure.in that the developer then customizes. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
"Geoffrey" == Geoffrey Wossum [EMAIL PROTECTED] writes: Geoffrey I was thinking about this, and I considered another Geoffrey possibility. autopkg would scan the Makefile.am to build a Geoffrey basic specfile, which the developer could then add pre/post Geoffrey install scripts and so forth. This would be analogous to Geoffrey autoscan producing a basic configure.in that the developer Geoffrey then customizes. Unfortunately, I don't think it is that easy. First, Makefile.am contents can be conditional on the particular configuration. That is why you really want to deal with the post-configuration package (using `make') and not Makefile.am. Second, the more complex post-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Tom
Re: More an autopackage
Tom Tromey wrote: Unfortunately, I don't think it is that easy. First, Makefile.am contents can be conditional on the particular configuration. That is why you really want to deal with the post-configuration package (using `make') and not Makefile.am. Second, the more complex post-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Good point, but the general design I pointed out should still hold. Only the generated Makefile would be the source for the data needed for spec file generation rather than the Makefile.am, whether that's passed in or scanned. The pre/post install hair should be scannable from the Makefile as well, whether that's for a shared library or info. The spec file source would want room for install hooks as well, still. That way instructions for, say, taking a daemon down and up again could be inserted before automake acquires a daemon target. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Teacher is not a leper. Teacher is not a leper. Teacher is not a leper... - Bart Simpson on chalkboard, _The Simpsons_
More an autopackage
Hi again, I want to work on the unified front-end to native packaging systems like I posted before, but the bossman doesn't want to wait until that's useable. So the autopackage front-end is going to be YASP (yet another side project) for me. Anyway, here's some of my thoughts about it: 1) written in Python 2) At first, it'll just be a unified front-end to rpm and dpkg and friends. Then, some of the more difficult issues that have been brought up will be tackled, such as package dependencies and automagically deciding the right files and locations for platforms. 3) I think the interface to it will be a file specifying the requirements for the package. Files to include, where to install them, pre and post install scripts, etc. At first, developers just write this file by hand. Even this is a great improvement. Then, automake gets modified to be able to automatically create this spec file. (Is this a good idea?) 4) Is autopackage a good name? 5) I'm really a software developer, not a packaging guy. That's why this seems like such a good idea. I want to write code, not mess with packaging systems. But, I really don't know that much about packaging. So I'll probably need some help with the packaging details. 6) When I get going with Actual Code (TM) (within a couple of weeks), I'll setup a project on sourceforge for this. And finally, thanks to everyone who responded to my initial post. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
On Thu, 18 Jan 2001, Geoffrey Wossum wrote: I want to work on the unified front-end to native packaging systems like I posted before, but the bossman doesn't want to wait until that's useable. So the autopackage front-end is going to be YASP (yet another side project) for me. Anyway, here's some of my thoughts about it: 1) written in Python Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) 5) I'm really a software developer, not a packaging guy. That's why this seems like such a good idea. I want to write code, not mess with packaging systems. But, I really don't know that much about packaging. So I'll probably need some help with the packaging details. 6) When I get going with Actual Code (TM) (within a couple of weeks), I'll setup a project on sourceforge for this. No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm issues once you have got started. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
Re: More an autopackage
On Jan 18, 2001, David Lee [EMAIL PROTECTED] wrote:
On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
1) written in Python
Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
(Indeed, isn't automake already in Perl? Why choose something different?
Especially when that something is considerably less widely installed?)
Because Perl is almost unreadable and Python is a very nice language?
6) When I get going with Actual Code (TM) (within a couple of weeks),
I'll setup a project on sourceforge for this.
No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm
issues once you have got started.
One may find a lot about packaging for native systems in the Samba CVS
tree. See www.samba.org.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: More an autopackage
Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) Because Perl is almost unreadable and Python is a very nice language? No GNU build tool can be written in a language already used by another tool. Since people already have to know sh, m4, and makefile syntax to use autoconf automake, those three are out, and Perl is out because automake used it. autoILOVEYOU, the GNU viral installer, is written in Visual BASIC and Microsoft Word macros, so autopackage is left with Python. (Perl seems readable enough for automake...) --Rusty
Re: More an autopackage
Anyway, here's some of my thoughts about it: 1) written in Python Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) I originally considered Perl5, basically because automake is in Perl (Perl4 to be precise). But this project screams object-oriented, and Perl's OO support is pretty kludgy. I think Larry Wall even says that in Programming Perl. Python's OOP support is much better. Passing self to every method is kindof kludgy, but overall it's much better than Perl's OO. I've never written a large project in Python, but I have in Perl. Another reason I would choose Python ;) In the same vein, I have noticed a shift in the community's preferred scripting language away from Perl towards Python. This said, I would still probably choose Perl over Python for a quick and dirty script. If someone wants to contribute code to the project, but don't know the implementation language, Python is much easier to learn than Perl. I know a large number of programming languages. C, C++, Java, Visual Basic, Perl, Python, LISP, Scheme, Tcl, Fortran, S370/68k/x86/PIC ASM... most languages that have enjoyed significant popularity except for COBOL. And Perl was by far the most difficult to learn. The install base is an important issue. My Solaris, Tru64, and Irix boxes have Perl, but not Python. But they didn't come with Perl out of the box, somebody had to install Perl. So I don't think also installing Python is that big of a deal. And all modern Linux distros include Perl and Python out of the box. No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm issues once you have got started. Thanks. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
On Thu, 18 Jan 2001, Geoffrey Wossum wrote: Anyway, here's some of my thoughts about it: 1) written in Python Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) I originally considered Perl5, basically because automake is in Perl Aren't we supposed to use GNU guile for all FSF-supported script-based tools? In fact, isn't Automake itself intended to be eventually re-written in guile? If you don't like the current languages that guile supports, you can always write a Python implementation that runs under guile (as they did for Tcl) and implement using Python syntax. Ducking and running ... Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: More an autopackage
"Bob" == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob Aren't we supposed to use GNU guile for all FSF-supported Bob script-based tools? In fact, isn't Automake itself intended to be Bob eventually re-written in guile? Yes, that is the intent. I doubt I'll be doing the work though. Tom
Re: More an autopackage
"Geoffrey" == Geoffrey Wossum [EMAIL PROTECTED] writes: Geoffrey Anyway, here's some of my thoughts about it: Geoffrey 1) written in Python The required language flame war has already started. However I think the implementation language is the least important thing. The important thing is getting the design right; then it can be expressed in any decent language. Geoffrey 3) I think the interface to it will be a file specifying the Geoffrey requirements for the package. Files to include, where to Geoffrey install them, pre and post install scripts, etc. At first, Geoffrey developers just write this file by hand. Even this is a Geoffrey great improvement. Then, automake gets modified to be able Geoffrey to automatically create this spec file. (Is this a good Geoffrey idea?) Automake can't create all of the spec file. It doesn't have enough information. And, adding the information to Makefile.am does not make sense (because it is global to a package, which Makefile.am really isn't). Also, generating a list of files is not enough. You also need pre- and post- install and uninstall commands. One way to get these is the *_INSTALL variables, which I talked about earlier. Another important consideration, I think, is designing the interface that represents the back end. Doing this correctly will allow for plugging in various different back ends. There are probably 6 or 7 package implementations these days... Geoffrey 4) Is autopackage a good name? Yes. Geoffrey So I'll probably need some help with the packaging details. There's lot of reading in your future... Tom
Re: More an autopackage
Has anybody looked at (epm) Easy Package Manager (http://www.easysw.com/epm/?
From the FAQ:
--
It is a simple tool that generates software and patch distributions in
various formats, including:
ATT Software Packages ("pkg"), used by Solaris.
Debian Package Manager ("dpkg")
HP-UX Software Packages ("swinstall" or "depot")
IRIX Software Manager ("inst" or "tardist")
Portable (installation and removal scripts with tar files)
Red Hat Package Manager ("RPM")
--
You provide a list file and epm can generate different packages based on
that. EPM is under GPL. Would it make sense for automake or autopackage to
generate epm list files instead of rpm or dpkg specific scripts?
Ganesan
--
R. Ganesan ([EMAIL PROTECTED]) | Ph: 91-80-5721856 Ext: 2149
Novell India Development Center. | #include std_disclaimer.h
