The impact of multiarch on upstream Python

[Barry Warsaw]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110421/1537f0bb/attachment.pgp>