Toshio Kuratomi wrote: > I'm not 100% certain but I think that Josselin is speaking of glibc in > particular here and you're speaking of c libraries in general.
Maybe, but I don't see how this change the point: when you change the soname of a library, it has 0 impact on the source code of the software which links against it. That's not true in python. > > > I've said before that ideally a Linux distribution only wants one > version of a library. And ideally, developers do not want to care about versioning issues :) There is a middle ground to find; up to now, I think python distutils and co did not care at all about this, but you can not ask to move 180 degrees and do only as linux vendors want. I understand the reasons why OS vendors want to avoid distributing multiple versions as much as possible. But that's just not realistic in every case. Even in C-derived languages, this is sometimes a PITA. I could give you examples where distributions screwed up the packaging badly and hurt some projects I am involved with. But that would be unfair and besides the point (we all screw up); the point is that there are some practical reasons for sometimes including private copies. Because for example in Fortran's case, there is this huge mess of gfortran and g77 not being ABI compatible; there are examples in C++, and even in C. You also can't impose every software to follow distributions time-schedule. Reasons for single version for OS vendors are valid; but so are the ones to have multiple versions. I think compat modules would cover most needsl the problem is that python does not have a mechanism to request a particular version of a module. But wouldn't this help OS vendors to have such a mechanism (to decrease the burden of compat versions ?) > In Fedora we're willing to have compat packages > that hold old API versions if we must but by and large we would rather > help upstream apps port their applications forward than to have > compatibility packages. Yes, but here again the C comparison breaks. Some people use python as a "tool", not so much as a "programming language". Their applications are scripts, or softwares for experiment, that are not released, because they can't open source it, or simply because it has no use for anyone else. You can't port that. cheers, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
