Fun with python-apt
I've managed to get python-apt (and thus apt-listchanges) working again on my testing system. What a PITA... Anyway, I first just tried to recompile python-apt-0.5.4.3. Compile went fine, but the first attempt to execute apt-listchanges failed with a dynamic linking error. C++ API change. First, I thought there was supposed to be a transition plan that would guard against such things happening. Is some package (apt?) not following it? So, I finally managed to get it to compile with gcc 2.95, and it works. But doing that was (at least for me, not being familiar with python) quite difficult. So here's my question about python packages (and the reason for cc'ing debian-python): Is there a better way to specify which compiler to use than to edit /usr/lib/python2.2/config/Makefile ? Anyway, if you want apt-listchanges back, all you have to do is change /usr/lib/python2.2/config/Makefile (temporarily) to say gcc-2.95 instead of gcc, then recompile python-apt. PS: I am not subscribed to debian-python; please CC me on replies. signature.asc Description: This is a digitally signed message part
Re: Fun with python-apt
On Saturday, Jun 14, 2003, at 01:40 US/Eastern, Matt Zimmerman wrote: If you had wanted to find out the answer before sending this to debian-devel, you would not have had to look very far. bugs.debian.org/python-apt has the answer three times over. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193566 My two questions were: 1) Why did dpkg-buildpackage wind up compiling with the wrong compiler? Isn't there a C++ transition plan that should prevent that. 2) Is there are better way to tell Python's building stuff which compiler to use? As far as (1), I ensured that all the build-time dependencies, as well as build-essential, were satisfied. According to Policy 2.4.2, it should work. It didn't. As far as (2), the only way I could find was to edit a makefile hiding in /usr. It ignored the environment (e.g., $CC), it errored out if I put CC=gcc-2.95 on the command line either before or after the target, etc. I do not believe 193566 comes anywhere near close to answering either of those questions. I also described a procedure that will get apt-listchanges working again. PS: I'm not subscribed to debian-python
Re: Fun with python-apt
On Saturday, Jun 14, 2003, at 18:45 US/Eastern, Matt Zimmerman wrote: My two questions were: 1) Why did dpkg-buildpackage wind up compiling with the wrong compiler? Isn't there a C++ transition plan that should prevent that. python-apt will, by default, use the default compiler on your system. Why would it do anything else? In a perfect world, somehow the correct gcc would be used (to make sure C++ ABI problems don't happen). Not sure if we can have that perfect world or not; see below. 2) Is there are better way to tell Python's building stuff which compiler to use? I do not know of a straightforward way. Guess I should file a wishlist bug. As far as (1), I ensured that all the build-time dependencies, as well as build-essential, were satisfied. According to Policy 2.4.2, it should work. It didn't. According to 2.4.2, the package should build correctly. It did. However, it didn't run because you had an incompatible version of apt installed. "If build-time dependencies are specified, it must be possible to build the package AND PRODUCE WORKING BINARIES In particular, this means that version clauses should be used rigorously in build-time relationships so that one CANNOT PRODUCE BAD OR INCONSISTENTLY CONFIGURE PAKAGES when the relationships are properly satisfied." (Policy 2.4.2, Emphasis added) 2.4.2 says the package has to work, too. The dependency system does not have a facility to handle this situation. That could be. Somehow, the C++ ABI would have to be added to the Build-Dependency information. Either that, or C++ packages would have to use a specific C++ ABI compiler, e.g., (control) Build-Depends: c102, ... (rules) CXX=g++-c102 I think that might work, but it's far, far too late to fix woody. However, since there is another ABI change coming up (I think I've heard there is), maybe it's time to consider it? [Haven't given this much thought. It should probably only be required for packages that either contain or link against a C++ library other than libstdc++.] It explains that python-apt in testing is broken, and no new version of python-apt will get into testing until the new apt does, and that won't happen until its RC bugs are fixed. Sure. The binaries are broken. The source happens to work just fine (with some manual hacking to make it build right).
Re: Fun with python-apt
On Saturday, Jun 14, 2003, at 19:17 US/Eastern, Matt Zimmerman wrote: This was before woody released, before there was any kind of C++ ABI transition plan, before there was even a g++-3.2 in the archive. Surely you aren't suggesting that last year's build-dependencies should have anticipated this year's compiler ABI change. Well, we all knew the ABI was changing long before that, actually. Remember the RedHat GCC 2.96 mess? We knew that GCC 3.0 would have a different ABI. Now, we know there will be another ABI change. We should plan for it. http://gcc.gnu.org/ml/gcc/2003-01/msg01763.html
Re: Fun with python-apt
On Sunday, Jun 15, 2003, at 15:50 US/Eastern, Matt Zimmerman wrote: Er, no. Those binaries would work perfectly fine if you had built apt with the same C++ ABI. But I can't specify in a build-dependency "oh, and your apt must be built with the same C++ ABI". I _certainly_ can't do so retroactively. I agree you certainly can't. This C++ transition wasn't being thought about back then; nothing can be done about that. However, we might be able to do something for the next transition.
