Michael Tautschnig wrote:
- dependencies on g++ *Version 3.4.2* - why does it depend on exactly
this single version
In general, all versions of GCC have changed the implemented C++ ABI in one way or another. This means that you cannot expect a C++ library compiled with GCC version x to work with a C++ program compiled with GCC version y if x != y. The situation will no doubt improve in the future, but up to now things have been like this (to put it more directly: the user should use the very same version of g++ the packager did use).
This is problably true for the first minor version (such as 3.3 or 3.4), but I doubt it is true for versions such as 3.4.2 and 3.4.3 ... - you should note, that Debian knows the packages g++-3.3 and g++-3.4, but g++ is just a metapackage depending on g++-3.3 - thus a dependency on g++(=3.4.2) is IMHO unsatisfiable.
From the GCC mailing lists I gather that the _implemented_ C++ ABI changes more frequently than people believes (another thing is, of course, the _published_ C++ ABI). However, taking your note as a starting point, I have made a little research and discovered that the Debian people seem to be rather concerned about incompatible ABI changes (this cannot be generalized: see, for instance, https://www.redhat.com/archives/fedora-devel-list/2005-February/msg01233.htm...). I am thus changing the dependency to (== 3.4).
Then, both 3.4.1 and 3.4.3 have bugs that affect the library. For 3.4.1 I was not completely sure the bug was in the compiler (as opposed to binutils or some other component of the toolchain). For 3.4.3 the situation was much worse and I had to quickly uninstall that version of the compiler from my machines.
I doubt these bugs are still contained in the current version of g++-3.4 in Debian - very likely they would have been reported to the Debian-BTS already. Furthermore version 3.4.2 is not available in Debian (anymore)
- and a dependency on a single version is always dangerous ...
OK.
Finally, I believe we now depend on C++ features that are not correctly supported by 3.3.x.
Hmm - I built and used the library successfully, but only very small parts of this library :-)
And probably only on one architecture, only with a single combination of configure options and so on and so forth :-)
- missing dependencies on automake1.9 and autoconf
Automake and autoconf are only needed by developers. People downloading tarballs or packages do not need Automake, Autoconf or Libtool. This is, at least, the intention. If I am mistaken, please let me know.
But they are required to build the package, aren't they? Thus I suppose they should be listed as build-dependencies ...
Yes, they are required to build the package. Also Doxygen is required. I am adding all of these to the build-dependencies. However, do not expect this to work reliably: the truth is that a very recent version of Doxygen is required in order to build the documentation and the Debian packaging system does not seem to allow specifying this.
Another two points:
- Shouldn't it be called libppl instead of ppl?
I don't know. What are the rules of the game? We tend to call our thing PPL and, unless we have very good reasons to call it differently, we would like to stick to it. From words, I gather there is a Debian convention for that. Can you point me to the relevant documents?
- To allow multiple versions of ppl being installed at the same time
(probably because of the g++-dependencies mentioned above), a version-number should be appended to the name of the main package, such as libppl0 or libppl8
OK. But this means we should probably have `control.in' instead of `control' so as to use autoconf to stick the right number in the package name. Are there conventions/standards on how to choose that number?
Thanks for all your great afford,
Thanks to you! Please keep your comments coming. All the best,
Roberto