[PPL-devel] RFC: packaging the PPL for RedHat and Debian

[Matthew Mundell]

Roberto Bagnara <bagnara at cs.unipr.it> writes:

> I would like to receive some advice about the packaging of the PPL,
> both for RedHat/Fedora and for Debian.  Things that are not clear
> to me is
>
> 1) how many packages should we have and what should they contain, and
> 2) how should the packages be named.
>
> For RedHat, we currently have a base package called `ppl' containing
> the core library, plus the documentation and the ppl_lcdd program.
> Then we have the C, GNU Prolog, SWI Prolog, SICStus Prolog and YAP
> Prolog interfaces in the `ppl-c', `ppl-gprolog', `ppl-swi', `ppl-sicstus'
> and `ppl-yap' packages, respectively.  The Parma Watchdog Library
> is currently included in the PPL and has a package called `ppl-pwl'.
> Finally, debug information if in `ppl-debuginfo'.
>
> Michael has suggested that we should name the package `libppl1' and
> I think he will explain us whether this is an important convention
> of Debian or just a matter of personal taste.  I do not think that,
> for the PPL, sticking the number after the name is a great idea:
> our library is so special-purpose that coexistence on one system
> of multiple incompatible versions is quite unlikely.  In the unlikely
> case this proves to be necessary we will see what to do: e.g.,
> if we have many users depending on PPL 2.45 at the time when we
> release a backward-incompatible PPL 3.0, we will generate a `libppl2'
> or `ppl2'.

Sounds sensible.

> I guess that, with the proposal of naming the package `libppl' instead
> of `ppl', goes the suggestion that programs like `ppl_lcdd' should not
> go in that package.  The question is now how many packages should we have.
> Another issue concerns documentation: should it go in the base package,
> in the `ppl-devel' package, or in a `ppl-doc' package?
> Should static libraries go to the devel package rather than the
> base one?

>From the policy manual:

    In general, libraries must have a shared version in the library
    package and a static version in the development package.  The
    shared version must be compiled with `-fPIC', and the static
    version must not be.  In other words, each source unit ( `*.c',
    for example, for C files) will need to be compiled twice.

and later:

    All libraries must have a shared version in the `lib*' package and a
    static version in the `lib*-dev' package.  The shared version must be
    compiled with `-fPIC', and the static version must not be.  In other
    words, each `*.c' file will need to be compiled twice.

which also shows the convention of prefixing library names with `lib',
and suffixing development names with `-dev'.

> Should we provide versions enabled for profiling?

A few libraries do this:

ghc5-prof - Profiling libraries for the Glasgow Haskell Compilation system
kaffe-pthreads-profile - A POSIX threads and profiling enabled version of the Kaffe VM
libc6-prof - GNU C Library: Profiling Libraries
libncurses5-dbg - Debugging/profiling libraries for ncurses
libpth-prof - The GNU Portable Threads (for profiling)
libroy1-prof - Utility and data structure library (profiling files)

It might be best to do this when someone needs it.

> By the way: it seems that in Debian development packages use "dev"
> instead of "devel".   Is this correct?

Yes, as Michael said.

> I would encourage you to look at %files `ppl.spec.in' in CVS head
> and come up with proposals on how to package the PPL both on RedHat
> and on Debian.

On Debian some libraries come with a separate documentation package,
which is nice for situations where a smaller installation is required.
For example:

libctl-dev - Library for flexible control files, development version
libctl-doc - libctl documentation in HTML format

libcoin40 - high-level 3D graphics kit with Open Inventor and VRML97 support - runtime
libcoin40-dev - high-level 3D graphics devkit with Open Inventor and VRML97 support
libcoin40-doc - high-level 3D graphics kit with Open Inventor and VRML97 support
libcoin40-runtime - high-level 3D graphics kit - external data files

libcorelinux - Foundation Classes, Design Patterns, IPC and Threads
libcorelinux-dev - Foundation Classes, Design Patterns, IPC and Threads
libcorelinux-doc - Foundation Classes, Design Patterns, IPC and Threads
libcorelinux-examples - Foundation Classes, Design Patterns, IPC and Threads

So how about a libppl-doc?

>                If you feel you are qualified only on one of these
> packaging systems, please feel free to disregard the other one
> (even though at the end I would like to enforce some sort of
> consistency between the two).

Perhaps there's an existing way to create one from the other.