[PPL-devel] Re: debian/control: build-depends

[Roberto Bagnara]

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

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