RFC: packaging the PPL for RedHat and Debian
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'.
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'.
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?
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. 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). All the best,
Roberto
Hello,
just to make one thing clear - I can only speak for Debian, I do not know any of RedHat/Fedora's conventions - but if any conflicts arise, I would always opt for some compromise instead of sticking to any specific schemes ...
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.
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
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
[...]
Hope to help, Michael
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
[...]
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.
Why does this interfaces-package depend on those systems - isn't it the other way round (if one intends to use PPL)? But ...
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.)
... that kills my idea anyway :-) I'll try to provide a summary as of tomorrow morning - thanks for the links!
Till then, Michael
Michael Tautschnig wrote:
[...]
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.
Why does this interfaces-package depend on those systems - isn't it the other way round (if one intends to use PPL)? But ...
You may need the language X development environment installed for installing the X-PPL interface. If you package the interfaces X-PPL, Y-PPL and Z-PPL together you may end up with the situation where the user is only interested in X-PPL but is required to have also Y installed in order to install the single interfaces package. This is something we want to avoid right from the start. Cheers,
Roberto
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.
Why does this interfaces-package depend on those systems - isn't it the other way round (if one intends to use PPL)? But ...
You may need the language X development environment installed for installing the X-PPL interface. If you package the interfaces X-PPL, Y-PPL and Z-PPL together you may end up with the situation where the user is only interested in X-PPL but is required to have also Y installed in order to install the single interfaces package. This is something we want to avoid right from the start.
I'm sorry, but I still don't get the point - why would I need the "language X development environment" to install a library? IMHO
- it might be required to build it -> build-depend or - the library alone is of course not useful -> Suggests: ...
Would you mind giving an example - I just don't understand ...
Sorry, Michael
Michael Tautschnig wrote:
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.
Why does this interfaces-package depend on those systems - isn't it the other way round (if one intends to use PPL)? But ...
You may need the language X development environment installed for installing the X-PPL interface. If you package the interfaces X-PPL, Y-PPL and Z-PPL together you may end up with the situation where the user is only interested in X-PPL but is required to have also Y installed in order to install the single interfaces package. This is something we want to avoid right from the start.
I'm sorry, but I still don't get the point - why would I need the "language X development environment" to install a library? IMHO
- it might be required to build it -> build-depend or
- the library alone is of course not useful -> Suggests: ...
Would you mind giving an example - I just don't understand ...
It may be because byte-code needs to be regenerated by the exact version of the environment that will be used by the user, it may be because proper installation requires to detect some features of the available development environment, it may be because an index file to the available modules needs to be updated, it may be because optional interfaces or their documentation are best installed into a directory that only exists and is known if X is already installed. There are a number of possible reasons. In general, you cannot expect the installation procedure of the development environment of language X to know about some obscure X-PPL interface. But the X-PPL can know about X and may have to in case we want to simplify the user's life. For example, we may decide to make the life of X-Prolog/PPL users simpler by installing under /usr/local/lib/X/X-<version>/... We can do so reliably only if X-Prolog version <version> is already installed. Remember that we often work with software/languages that are no more than research prototypes: we cannot expect they always do the right thing or provide the same functionalities/flexibility one can find in more professional software. Cheers,
Roberto
[...]
It may be because byte-code needs to be regenerated by the exact version of the environment that will be used by the user, it may be because proper installation requires to detect some features of the available development environment, it may be because an index file to the available modules needs to be updated, it may be because optional interfaces or their documentation are best installed into a directory that only exists and is known if X is already installed. There are a number of possible reasons. In general, you cannot expect the installation procedure of the development environment of language X to know about some obscure X-PPL interface. But the X-PPL can know about X and may have to in case we want to simplify the user's life. For example, we may decide to make the life of X-Prolog/PPL users simpler by installing under /usr/local/lib/X/X-<version>/... We can do so reliably only if X-Prolog version <version> is already installed. Remember that we often work with software/languages that are no more than research prototypes: we cannot expect they always do the right thing or provide the same functionalities/flexibility one can find in more professional software.
Ok, thanks - I got the point. Although I do not fully agree to the above, I do not know any better and thus I opt for a single package per language too. Still, I will take a careful look at debian/control to see, whether we could find a -- from my point of view -- better solution, at least for debian. There are solutions, such as /etc/alternatives , that might help in some cases.
Thank you for your patience, Michael
... that kills my idea anyway :-) I'll try to provide a summary as of tomorrow morning - thanks for the links!
So - it's not "morning" anymore, but finally I found the time to read the articles - and a really short summary would read:
- The Name: lib<libraryname><soversion> and lib<libraryname>-dev , if there is no need for multiple versions of the dev-files.
- The Contents: Any additional binary (such as ppl_lcdd) might go into lib<libraryname><soversion>-runtime or lib<libraryname>-dev ; Furthermore only lib<libraryname>-dev may (and should) provide a symbolic link in /usr/lib/lib<libraryname>.so to /usr/lib/lib<libraryname>.so.<soversion>
Furthermore, it is ok to have multiple libraries in a single package. Last, but not least, the shlibs-system should be used to provide the necessary dependency-information - please read and follow
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shli...
HTH, Michael
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.
ppl-interfaces could be a virtual package that installs all the ppl interface packages.
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.
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
[...]
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.
Well, where is the problem? Yes, IMHO all packages should provide these files, but in Debian the usually go in /usr/share/doc/<packagename>/ , so there won't be any conflict to be resolved; acutally, by listing those files in debian/docs, that will be done automatically for each package. It might be considered wasted disk-space, but that should be about all.
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.
Well - do you really think we should have more than one -dev -package? In boost, they do that - but each package provides quite a few header-files - which is AFAIK not the case for ppl!?
I'd opt for
- libppl<soversion> - libppl-<language><soversion> - libppl-dev - libppl-doc
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.
The only thing I found was "epm" - see
http://www.samag.com/documents/s=8964/sam0312h/0312h.htm
- otherwise I suggest writing an awk-script that does the job automatically!?
Regards, Michael
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.
Well - do you really think we should have more than one -dev -package? In boost, they do that - but each package provides quite a few header-files - which is AFAIK not the case for ppl!?
I'd opt for
- libppl<soversion>
- libppl-<language><soversion>
- libppl-dev
- libppl-doc
An alternative:
- libppl5 - libppl5-<language> - libppl5-dev ; which includes all interface dev - libppl5-doc
Is 5 correct? With the CVS head installed, this:
objdump -p /usr/local/lib/libppl.so | grep SONAME
returns:
SONAME libppl.so.5
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.
At a first glance it looks like the mapping could be straightforward.
The only thing I found was "epm" - see
This might be useful. The Debian README notes the lack of garauntee that packages will conform to the policy.
http://www.samag.com/documents/s=8964/sam0312h/0312h.htm
- otherwise I suggest writing an awk-script that does the job automatically!?
Instead of generating one from the other, both could have the common information inserted. So some sort of preprocessor could insert text into each configuration.
The configurations are pretty small though, so it might just be easier to edit both as they change.
Matthew Mundell wrote:
I'd opt for
- libppl<soversion>
- libppl-<language><soversion>
- libppl-dev
- libppl-doc
An alternative:
- libppl5
- libppl5-<language>
- libppl5-dev ; which includes all interface dev
- libppl5-doc
Is 5 correct? With the CVS head installed, this:
objdump -p /usr/local/lib/libppl.so | grep SONAME
returns:
SONAME libppl.so.5
The name would have change from release to release, since we are nowhere near to offer any kind of backward compatibility. We cannot offer source compatibility, let alone binary compatibility. If this proposal means we have to create by hand files called libppl<n>* for <n> = 5, 6, 7, ... one unrelated from the other as far as CVS is concerned, then I oppose this proposal. Even automatizing the creation of this files names libppl<n> from another source with a stable name seems _really_ overkill at this stage. Our 5 Debian users will have to uninstall the old PPL version when installing a new one. Keeping them both would be completely nonsensical today and even two years from now. The parallel with libc makes no sense: in a GNU/Linux system _everything_ depends on libc, so there this versioning thing is vital to make the system practically upgradable.
I propose we try to end up with something that works, to start with, omitting the version number from the package names. When we have something that works, then we will decide what to do... trying not to forget that the best is the enemy of the good.
So Matthew, what do we miss to make this Debian packaging system happy? Ciao,
Roberto
The name would have change from release to release, since we are nowhere near to offer any kind of backward compatibility. We cannot offer source compatibility, let alone binary compatibility. If this proposal means we have to create by hand files called libppl<n>* for <n> = 5, 6, 7, ... one unrelated from the other as far as CVS is concerned, then I oppose this proposal. Even automatizing the creation of this files names libppl<n> from another source with a stable name seems _really_ overkill at this stage. Our 5 Debian users will have to uninstall the old PPL version when installing a new one. Keeping them both would be completely nonsensical today and even two years from now. The parallel with libc makes no sense: in a GNU/Linux system _everything_ depends on libc, so there this versioning thing is vital to make the system practically upgradable.
I propose we try to end up with something that works, to start with, omitting the version number from the package names. When we have something that works, then we will decide what to do... trying not to forget that the best is the enemy of the good.
Ok, that's just fine - I'll still try to find a solution - and if I find one, I will tell you... But - there is no need to uninstall the packages manually - if you just increase the version numbers, the debian-packaging system will take care of uninstalling older versions (of the same package). If you ever rename it to libppl<version-number>, you could add a "Replaces: libppl" - line to the control file.
So Matthew, what do we miss to make this Debian packaging system happy?
Well, my name is not Matthew - but I suggest
- debian/docs should probably contain BUGS README TODO and CREDITS - debian/rules is still missing
Regards, Michael
Michael Tautschnig wrote:
So Matthew, what do we miss to make this Debian packaging system happy?
Well, my name is not Matthew - but I suggest
- debian/docs should probably contain BUGS README TODO and CREDITS
TODO is for internal use only.
In contrast, you are not mentioning
ChangeLog NEWS README.configure doc/README.doc
Is the omission intended? In other words, what is the exact semantics of the `debian/docs' file?
- debian/rules is still missing
I am sure one does not start from scratch writing one. Does Debian provide a standard starting point? I mean: we have a "configure, make, make install" build system afterall. Cheers,
Roberto
P.S. I am not CCing Matthew or Andrea because they already are on ppl-devel.
[...]
- debian/docs should probably contain BUGS README TODO and CREDITS
TODO is for internal use only.
In contrast, you are not mentioning
ChangeLog NEWS README.configure doc/README.doc
Is the omission intended? In other words, what is the exact semantics of the `debian/docs' file?
No, I'm sorry - it was rather a very quick listing of some examples; debian/docs may contain any file to be installed in /usr/share/doc/<packagename> - it is not required, if the files are simply listed in <packagename>.install .
- debian/rules is still missing
I am sure one does not start from scratch writing one. Does Debian provide a standard starting point? I mean: we have a "configure, make, make install" build system afterall.
Debian provides dh_make to create such a file for you - as you're not using debian, you probably don't have that tool. I could send you mine, if you like (as generated by dh_make + autoconf-addons)?
P.S. I am not CCing Matthew or Andrea because they already are on ppl-devel.
Makes me ask: Should I send my mails to the list directly, or just CC the list, as I'm doing up to now?
Regards, Michael
Roberto Bagnara bagnara@cs.unipr.it writes:
Michael Tautschnig wrote:
So Matthew, what do we miss to make this Debian packaging system happy?
Well, my name is not Matthew - but I suggest
- debian/docs should probably contain BUGS README TODO and CREDITS
TODO is for internal use only.
Many packages include TODO lists. They are nice for gauging the state and plans of a project.
In contrast, you are not mentioning
ChangeLog NEWS README.configure doc/README.doc
ChangeLog and NEWS should be included, the other two are only relevant for building.
Is the omission intended? In other words, what is the exact semantics of the `debian/docs' file?
- debian/rules is still missing
I am sure one does not start from scratch writing one. Does Debian provide a standard starting point? I mean: we have a "configure, make, make install" build system afterall.
It can be generated with dh_make, at which I'm having a go. Any advice welcome.
An alternative:
- libppl5
- libppl5-<language>
- libppl5-dev ; which includes all interface dev
- libppl5-doc
Is 5 correct? With the CVS head installed, this: objdump -p /usr/local/lib/libppl.so | grep SONAME returns: SONAME libppl.so.5
The name would have change from release to release, since we are nowhere near to offer any kind of backward compatibility. We cannot offer source compatibility, let alone binary compatibility. If this proposal means we have to create by hand files called libppl<n>* for <n> = 5, 6, 7, ... one unrelated from the other as far as CVS is concerned, then I oppose this proposal.
Yes, it will be too much work if compatibility is going to break often.
Keeping them both would be completely nonsensicaltoday and even two years from now. The parallel with libc makes no sense: in a GNU/Linux system _everything_ depends on libc, so there this versioning thing is vital to make the system practically upgradable.
I propose we try to end up with something that works, to start with, omitting the version number from the package names.
Many packages seem to do it like this, so it must be OK, even if the policy suggests a number.
So Matthew, what do we miss to make this Debian packaging system happy?
- debian/rules - debian/changelog - build dependency on graphviz - debian/control descriptions of the interface packages - debian/control source `Section' - dir, install and link files for the interface packages - debian/libppl.doc-base and debian/libppl-dev.doc-base
May I commit these changes?
Building the packages with the changes works, but the following error occurs when installing the libppl package. Anyone recognise the cause? Michael?
Selecting previously deselected package libppl. (Reading database ... 157147 files and directories currently installed.) Unpacking libppl (from libppl_0.8pre1-1_i386.deb) ... Setting up libppl (0.8pre1-1) ... error in control file: `Section' value not specified at /usr/sbin/install-docs line 606, <IN> line 4. dpkg: error processing libppl (--install): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: libppl
A `Section' line is present in the control file in the package.
Matthew Mundell wrote:
So Matthew, what do we miss to make this Debian packaging system happy?
- debian/rules
- debian/changelog
- build dependency on graphviz
- debian/control descriptions of the interface packages
- debian/control source `Section'
- dir, install and link files for the interface packages
- debian/libppl.doc-base and debian/libppl-dev.doc-base
May I commit these changes?
Yes, please!
Matthew Mundell mattm@comp.leeds.ac.uk writes:
So Matthew, what do we miss to make this Debian packaging system happy?
- debian/rules
- debian/changelog
- build dependency on graphviz
- debian/control descriptions of the interface packages
- debian/control source `Section'
- dir, install and link files for the interface packages
- debian/libppl.doc-base and debian/libppl-dev.doc-base
May I commit these changes?
Building the packages with the changes works, but the following error occurs when installing the libppl package. Anyone recognise the cause? Michael?
Selecting previously deselected package libppl. (Reading database ... 157147 files and directories currently installed.) Unpacking libppl (from libppl_0.8pre1-1_i386.deb) ... Setting up libppl (0.8pre1-1) ... error in control file: `Section' value not specified at /usr/sbin/install-docs line 606, <IN> line 4. dpkg: error processing libppl (--install): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: libpplA `Section' line is present in the control file in the package.
The cause was the format of the doc-base control file, so now the package installs successfully.
Should either of ppl_lcdd and ppl_lpsol be packaged? If so then should they go into the libppl package, to match the packaging of ppl_lcdd in the RPMs?
Matthew Mundell wrote:
Should either of ppl_lcdd and ppl_lpsol be packaged? If so then should they go into the libppl package, to match the packaging of ppl_lcdd in the RPMs?
Matthew,
only ppl_lcdd should be packaged. Packaging it into the libppl package seems a sensible thing to do. Cheers,
Roberto
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?
From the policy manual:
Packages distributed under the UCB BSD license, the Artistic license, the GNU GPL, and the GNU LGPL should refer to the files `/usr/share/common-licenses/BSD', `/usr/share/common-licenses/Artistic', `/usr/share/common-licenses/GPL', and `/usr/share/common-licenses/LGPL' respectively, rather than quoting them in the copyright file.
So for example in the Emacs 21 copyright file:
GNU Emacs is Copyright (C) 1985, 1986, 1987, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330 Boston, MA 02111-1307 USA and is covered under the terms of the GPL. See the file /usr/share/common-licenses/GPL for more information.
...
The Emacs 21 copyright file also refers to the GFDL in the Info directory, however the gcc-3.4 copyright file has:
The documentation is licensed under the GNU Free Documentation License (v1.2), appended at the end of this file.
which seems more in order.
As far as duplicating the copyright and licence, the policy manual includes:
`/usr/share/doc/PACKAGE' may be a symbolic link to another directory in `/usr/share/doc' only if the two packages both come from the same source and the first package Depends on the second. These rules are important because copyrights must be extractable by mechanical means.
So any PPL packages that depend on libppl can symlink to /usr/share/doc/libppl.
I mean: the GPL must be partof 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?
If the -dev package contains the documentation then yes, otherwise the comments surely fall under the GPL. A libppl-doc package would be nice. Perhaps this could include the interface docs, or the interface packages could include their own docs, to keep the number of packages down.
But then, why not distribute also the other files:README, BUGS, CREDITS...
These are often included, as Michael wrote, in /usr/share/doc/<package-name>, for example /doc/libdbi-perl contains:
Changes.gz README.gz ToDo.gz changelog.Debian.gz changelog.gz copyright examples/
If we want to have several packages these areall 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?
That will mean many packages. It should be alright to include the interface development files in libppl-dev.
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.
Matthew Mundell mattm@comp.leeds.ac.uk writes:
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.
Although, the Debian Library Packaging guide has:
Chapter 5. Naming library packages
The policy documents how to name library packages. "lib[libraryname][SONAME-version-number]" like "libc6" for /lib/libc.so.6
so it would be more in keeping to name it libppl5.
Also, should debian/compat in CVS hold 5, to match the current shared object version?
Although, the Debian Library Packaging guide has:
Chapter 5. Naming library packages
The policy documents how to name library packages. "lib[libraryname][SONAME-version-number]" like "libc6" for /lib/libc.so.6
so it would be more in keeping to name it libppl5.
Yes, but this makes me ask: Why is the soname-version == 5?
Also, should debian/compat in CVS hold 5, to match the current shared object version?
No, debian/compat is the compatibility-information for debhelper, see
man debhelper or
http://www.zevils.com/cgi-bin/man/man2html?7+debhelper
Regards, Michael
Michael Tautschnig wrote:
Although, the Debian Library Packaging guide has:
Chapter 5. Naming library packages
The policy documents how to name library packages. "lib[libraryname][SONAME-version-number]" like "libc6" for /lib/libc.so.6
so it would be more in keeping to name it libppl5.
Yes, but this makes me ask: Why is the soname-version == 5?
The answer is in src/Makefile.am, which is the only file I would like to modify in order so change this version information, for the time being.
# Libtool -version-info for libppl.la. # # 1. Start with version information of `0:0:0' for each Libtool library. # # 2. Update the version information only immediately before a public # release of your software. More frequent updates are unnecessary, # and only guarantee that the current interface number gets larger # faster. # # 3. If the library source code has changed at all since the last # update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). # # 4. If any interfaces have been added, removed, or changed since the # last update, increment CURRENT, and set REVISION to 0. # # 5. If any interfaces have been added since the last public release, # then increment AGE. # # 6. If any interfaces have been removed since the last public release, # then set AGE to 0. # # PPL release -version-info # 0.1 ----- # 0.2 ----- # 0.3 0:0:0 # 0.4 1:0:1 # 0.5 2:0:0 # 0.6 3:0:0 # 0.7 4:0:0 # 0.8 5:0:0
And you can bet that, at least for the next 5, 6, 7 releases, the CURRENT number will strictly increase. Cheers,
Roberto
participants (3)
-
Matthew Mundell -
Michael Tautschnig -
Roberto Bagnara