Roberto Bagnara bagnara@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
- how many packages should we have and what should they contain, and
- 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 thesepackaging 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.