Re: Package support (RPM, deb, pkg, kits, etc.)

[Tom Tromey]

>>>>> "Geoffrey" == Geoffrey Wossum <address@hidden> writes:

Geoffrey> Seeing as how packaging support doesn't seem to be here yet,
Geoffrey> I would like to work on it.

Geoffrey> 1) Is my evalution of automake's current lack of package
Geoffrey> support correct?

Yes.

Geoffrey> 2) Would it be preferable to add all the support into
Geoffrey> automake, or to create another utility (autopkg?) that would
Geoffrey> be integrated with automake?

Another tool, maybe with hooks in automake.

Geoffrey> 3) What implementation language would be preferred for
Geoffrey> another tool?  I would prefer Perl5, but I am open to
Geoffrey> suggestions from the community.

Doesn't matter to me.

Geoffrey> 4) What should the interface into the packaging support be?

I don't know.


I once looked at writing an `autopackage' tool.  The idea was to have
a small file that held all the metadata for the package (a superset of
the metadata used by dpkg and rpm) and then to use the *_INSTALL
macros in automake to extract the actual rules used to install
programs (there's a brief discussion of this in the GNU coding
standards).

This probably isn't too hard to implement.  In fact I started
implementing it and I think you can get my code somewhere.  (It is
very far from working but there might be enough there to show the
general idea.)

When doing this I discovered that I'd really need an addition to
automake to support it properly.  It is common for a single source
package to build several end user binary packages.  For instance a
library package typically has a `-devel' version that includes the
header files and documentation.

So the idea was to tell automake about different sub-packages so that
the `make' step in autopackage could be run once for each sub-package
and thus see only the required subset of the installed files.


There were two reasons I stopped doing this.

One reason is that it isn't clear that this is needed.  At least the
Debian and RPM communities have already solved these problems to their
satisfaction.  Introducing another tool would probably just make
things harder for Debian/RPM package maintainers.

The second, and more important, reason is that different systems have
different packaging requirements.  That is, Debian, Red Hat, SuSE,
etc, might all choose to break down a source package into binary
packages in different ways, and they all might have different package
names, etc.  There are similar things that are harder to fix, I think,
but I forget what they are.

Tom