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

[Roberto Bagnara]

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
>>
>> 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'.
>>
> 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:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273871

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:
> 
> http://packages.debian.org/testing/source/boost

This is useful too.

> Hope to help,

Thanks.  You can do more though :-)
Cheers,

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it