Re: More an autopackage

[Geoffrey Wossum]

> 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
address@hidden