Package creation with GNU tools

[Soeren D. Schulze]

Hello,

we have only spoken about how to control installed packages, not yet
about how to create and install them.
For the latter, you suggested using tar, which is, in my humble
opinion, a good idea because it is simple and transparent.  Information
about a package (long title, description, etc.) and its dependencies
could be stored in an additional file (extending the Lisp-style
dependency file that I suggested).  It could come seperately from the
plain source tarball (perhaps with it in a further tarball).
Beside the pure extraction, installation contains configuring and
setting up the package and the environment for each other.  Therefore,
packages in existing package management systems contains scripts that
are executed before and after the installation and removal
respectively.  The included commands are mostly distribution-specific,
so there is currently no direct need.  Moreover, the way the
environment is set up for the package -- including the provided files
in a database -- conflicts with providing several versions of a package
at the same time in some cases.
I wonder if we should have this feature in advance, anyway.

Even before installation, the package has to be created.  Existing
package managers use "source packages" for this purpose.  These contain
the usual tarball distribution -- packaged or unpackaged -- and
makefiles that control the building process.  (This is how Debian
handles it -- I am not familiar with RPM.)
The problem is:  They are on top of everything; executing them is the
only way to build the packages -- unless you want to call everything by
hand.  Of course, when you build a package via
./configure -- make -- make install, you do this by hand, too, but what
these makefiles call are tools that deprive those much more powerful
autoconf and automake -- whose output is nevertheless executed -- of
any power.  They are not just scripts that call the commands that you
would call by hand; they replace them.  In that case, it may make sense
because not every package should be forced to use autoconf and
automake, but in a GNU system, things are different.
Autoconf and automake are not designed to build packages, of course.
We could either change this by adding some features and/or provide some
_orthogonal_ scripts.  In no case, we should hack additional tools --
unless they are only for convenience purposes and do something that no
existing GNU tool provides properly.  A sample script is this:

mkdir bindist
cd bindist
CFLAGS="-g3 -O3 -march=athlon-xp -Wall -W -Wstrict-prototypes
-Wmissting-prototypes" ../configure --prefix=/
make
make install prefix=foo-0.1
tar czf foo-0.1.tar.gz foo-0.1

Yes, these few lines build build the binary tarball for any package
that uses autoconf and automake -- without any packaging work.
Only the description and dependency file is missing.

The convenience features that I spoke about are:
1. The build dependencies could be fullfilled automatically by
   installing the necessary packages.  This would require a build
   dependency file.  We could distinguish between building dependencies
   and suggestions; for the latter, autoconf checks their presence.
   Alternatively, for more complex dependencies, we could write an
   autoconf macro AC_INSTALL_PACKAGE that does the same.
2. The runtime dependencies could be calculated automatically by
   checking the dynamic linking.  Additional dependencies could be
   specified in the build dependency file.  For this, the dependency
   file should perhaps be seperated from the description file to make
   automatic generation easier.  (Possibly kitten could be useful
   somewhere.)

What do you think?


Soeren Schulze