Michael Tautschnig wrote:
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'.
As stated above, I do not know Redhat's conventions, but having many packages also implies having a lot of metadata. Furthermore I don't know the size of all the interface-packages, but assuming they are rather small, I personally would like the idea of only having one ppl-interfaces - package. Just an idea.
This package would have to depend on the availability of all 5 Prolog systems and, in perspective also of OCaml, Java, Mathematica, ... We need another idea.
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'.
Including a number is IMHO
- a question of how stable the interface of the library itself is
- whether dependencies on different versions of g++/libstdc++ should be
considered
- I don't know any official Debian-document regarding this issue, but
the following bugreport is the source of my concerns:
That thread contains two interesting links:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
However, I am too busy at the moment to read them. I leave it to you Debian users (Michael and Matthew) to make an executive summary for us to follow. (One of the things I have read is that they recommend not packaging more than one shared library into a single package: another reason not to have a `ppl-interfaces' package.)
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? Should we provide versions enabled for profiling? By the way: it seems that in Debian development packages use "dev" instead of "devel". Is this correct?
Yes, using "dev" is the correct way. To provide an example, I suggest looking at the naming-schema of the boost-libraries within Debian:
This is useful too.
Hope to help,
Thanks. You can do more though :-) Cheers,
Roberto