On Apr 20, 2011, at 10:19 PM, Matthias Klose wrote: >Python upstream, and many other upstream packages shouldn't need to search >for headers and libraries in the standard path of the compiler. It's done >very often, but the right thing is to use the compiler's idea of the search >paths and not to hardcode these on your own. gcc -v tells you about the >include paths, and gcc -print-search-dirs about the library paths.
>So if python's poor re-implementation of autoconf needs to search for files, >it should base it's search on these paths. > This would be a useful initiative to start in upstream Python. Do you know if there's even a bug open in the Python tracker? Of course, a change this big wouldn't be back portable to any stable releases, but could make a big difference for Python 3.3 and onward, especially where the insanity of distutils is going to be replaced. Still, the effects of the multiarch landing would have to be dealt with for earlier active Python branches. >> * More engagement earlier on with the Python developers to better >> communicate the impact of this platform change, and to discuss possible >> solution. > >yes, things like autoconf macros and makefile snippets would be nice, but the >primary goal here was to get it working first after it was introduced. Yep, and I realize that it's very difficult to fully understand the impact of so wide-ranging a change, until it actually lands and you start seeing what broke. My email is mainly to generate some discussion on how we could have done more testing, or otherwise experimented to try to identify the problems earlier on. >> * Consideration for backward compatibility so that Python's build would >> continue to work without change. > >that (having symlinks for the files in the old locations) would defeat the >benefit of multiarch. Wouldn't it give packages and projects a reasonable transition period to adapt to the changes? Did multiarch have to be an all-or-nothing change? >> * Some justification or explanation about how Ubuntu's change is part of a >> larger standardization effort, e.g. dpkg-architecture can't be a >> cross-distro API for determining the paths. > >> I suspect that Python won't be the only language (and possibly upstream >> project) affected by this change, so a better way to engage upstreams in the >> future is crucial. > >well, how many upstreams are affected by other changes like a new python >version, or a new compiler version? Usually upstreams do fix these things, >but not necessarily on the version that you currently have in the >distribution. So yes, you should "engage" upstreams, but nevertheless you'll >have to make it work in the distribution at the time the distributions needs >the change. Yep. I have no problem with the change you made to Natty's Python package -- that was perfectly reasonable! And it was the perfect basis for the patch I eventually did apply to Python (with some modifications to make it more cross-platform friendly). You're absolutely right that new Python versions or new compiler versions can break things. I can't speak to gcc, but Python is *supposed* to have a well-defined deprecation process to help people migrate. It doesn't always work as well as it should, but I shudder to think what would happen if no such policy was in place at all. Software is messy. ;) -Barry
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel