On Sun, May 01, 2011 at 11:04:42PM +0200, Andreas Barth wrote: > * Johann Felix Soden (joh...@gmx.de) [110501 21:52]: > > 3. Currently, the compiler version check is done at build time by > > calling g++-4.x explicitly if default gcj has version 4.x.y. But if > > gcc-defaults (or any other package) does not guarantee that g++-4.x is > > available, FTBFS can happen - better than frustrated users due to > > unusable pdftk but anything than optimal. > > Of course, the current situation is better than silent package > corruption. But still not ok, because that leads to hidden new bugs > jumping out at the wrong moment.
Yes, as I wrote, "anything than optimal". I should have tried to discuss the matter more before choosing the currently implemented "solution"... During the last week I did several checks with pdftk and different g++/gcj versions. pdftk 1.44 will not need to conflict with other libgcj-bc versions any more. Another result was, that in my eyes different default versions of g++ and gcj is really a serious bug, because then things like "g++ ... -lgcj" or "#include <gcj/cni.h>" are not working (since libgcj12-dev has its header in /usr/include/c++/4.6/gcj etc.). > > However, we (in sum) have two choices: > 1. have meta package(s) that make sure we have consistent compilers. > This could be gcc-defaults. It could also be e.g. some > gcj-g++-package. Or whatever else. We could assume, that nobody will try to use the g++/gcj combination. Then this option with a new (meta-)package seems to fit best in my opinion. We keep then the current "flexibility" with default gcj and gcc/g++ versions. If we take this option, some more things need to be discussed: - How can the right gcj/g++ version be detected during building of e.g. pdftk? Currently, the version of the default gcj is taken and then matching g++ version is called explicitly. But this will fail, if the default gcj has a newer version than newest available versions of g++. The other way round, we have the same problem. The solution would be, that the new package provides somehow the version of gcj/g++ that should be taken. - Who creates and maintains this new package? - As mentioned, the package name: gcj-g++-dev, gcj-g++, ... > 2. hardcode certain versions into this package. If we do not proceed with the meta-package, I will upload pdftk 1.44 to unstable with explicit g++-4.6, gcj-4.6 dependencies within the next few days. > > In case there is a third choice please say so. Yes, possibly gcj-jdk (or libgcj*-dev) could depend on the matching g++ version. Johann Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
