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

[Tom Tromey]

>>>>> "Michael" == Michael Still <address@hidden> writes:

>> lib_LIBRARIES = libfoo.a
>> devel_header_HEADERS = foo/foo.h

Michael> Why don;t you just have some different primaries? Like, for
Michael> instance:

Michael> rpm_PROGRAMS = foo
Michael> foo_SOURCES = foo.c wibble.c hamster.c

This means you have to introduce redundancy into your Makefile.am.
With the above, where is `foo' installed if I run `make install'?

I think it also doesn't make sense to have a single `rpm'.  Many
source packages will become more than one binary package.  It is
important to support this.

Instead I think I'd rather see something like package tags attached to
installable objects, as in my original quoted example.

These package names would be purely symbolic.  Autopackage would be
responsible for mapping these names to the real binary package names.

So for instance in the above example, `libfoo.a' would be in the
`default' package, which autopackage might reasonably name after
$PACKAGE.  `foo/foo.h' would be in the `devel' package.  On Debian
this would be $PACKAGE-dev, on Red Hat it would be $PACKAGE-devel.

Autopackage could also help with determining dependencies
automatically.


Here's what I wrote in my autopackage `TODO' file which explains the
automake part of the plan:

    Automake changes:

    Add AM_INIT_PACKAGES([names])
    Lists all the subpackages we define
    Define them rpm-style: suffixes

    If AM_INIT_PACKAGES(foo) is seen, then a Makefile.am can use `foo' on
    any installable object:

        foo_bin_PROGRAMS = ...

    Targets install-exec-foo and install-data-foo will be generated


    Add a new Automake primary, DOCUMENTATION
    `noinst' is the typical use?
    Provide a way to install it into a given directory

The idea behind DOCUMENTATION is to provide a way to install README
and the other stuff that ends up (eg) in /usr/doc/$PACKAGE.

Tom