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