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

[Roberto Bagnara]

Matthew Mundell wrote:
>>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.

Good.  These is already what the build procedure does.

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

OK.

> 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?

OK: let us see how this looks like.  How are the requirements of the GPL
and of the GFDL satisfied then?  I guess they should go in all packages
and not conflict with each other, right?  I mean: the GPL must be part
of the base package.  But it must be part also of the -dev package since
the -dev package would seem to be independent from the base one (it contains
the static library and the headers so it containts "the software" the same way
the base package containing the shared library contains it).  Since we
generate documentation from comments, the GFDL should also be part of the
-dev package, right?  But then, why not distribute also the other files:
README, BUGS, CREDITS...  If we want to have several packages these are
all problems that must be solved.

And, in all this separation: should we have both libppl-c and libppl-c-dev?
One with the shared library and one with the static one?
Arent we going to end up with 20 or so packages for something
that is not really that complicate such as the PPL?
Let us think about this.

>>               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.

I have looked around, but was not satisfied with what I found.
You can consider me the RPM expert: it is not completely accurate
but it is good enough for our purposes.

Matthew, can you elaborate things further?  Have a look at ppl.spec.in
that lists all the files that are installed by the RPM packages and
see how to map them into the Debian mechanism.
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