Re: some rpm building questions

[Rob Browning]

Bo Forslund <address@hidden> writes:

> I have some questions about how to pack a guile rpm.
>
>
> Would rpm packaging like this be good? Or should all .h files go to a
> -devel package?

One of the things that's been holding up the debian packages is that
I've been trying to make sure I get this right -- the debian packages
are already mostly right, but not completely.

First off, make sure to name your source package with the major
version information, i.e. guile-1.6, not just guile.  This prevents
(for example) distributions from losing the source to 1.4 even if the
binaries are still on their servers when 1.6 comes out.

With respect to the binary packages, my current thinking is:

  guile-1.6
    for the main app binary, etc.

  libguile12
    for ice-9, libguile, etc. -- this must be versioned so you can
    later have apps that link against libguile9 and libguile12
    installed at the same time.  If you don't allow that, then you
    can't incrementally upgrade your system.

  guile-1.6-dev
    should "provide guile-dev" and "conflict guile-dev".
    Until/unless we have a way to have several sets of headers
    installed and some way to specify which to use, you can't really
    allow multiple development packages to be installed at the same
    time, but is is useful to be able to switch back and forth between
    two versions.  This package should contain the the headers, etc.

  libguile-srfi-srfi-4-v-1
    similar to libguile12, but for the srfi lib.

  libguile-srfi-srfi-13-14-v-1
    similar to libguile12, but for the srfi lib.

  libguilereadline-v-12
    similar to libguile12, but for readline.

  libqthreads12
    similar to libguile12, but for qthreads.

Note that one might raise an objection to so many library packages,
especially with the version numbers in the name, but if you don't do
that you're in big trouble later on.  Trivial example: imagine we
release guile 1.8 with libguile.13.so, but we leave
libguile-srfi-srfi-4-v-1 at major number 1.  If we had just put all
the srfi libs in libguile, then the guile 1.8 libguile package and the
guile 1.6 libguile package would have conflicting files.

The general rule is: if you don't want to get in trouble later,
*always* package publically visible, directly linkable shared
libraries in their own packages, and put the major number in the name
so you can have more than one version installed at the same time.

I'm planning to fill out README-PACKAGING in full after I finish
working out the debian packages -- when I'll know more, but this is
what's in my head at the moment.

> guile-ltdl
>       conflicting libltdl here already

If you can, I'd hold off until we get 1.6.1 ready -- I'm hoping within
a couple of days -- this issue will go away and stay there.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD