On Fri, 2012-11-30 at 11:13 -0500, Barry Warsaw wrote:
> On Nov 30, 2012, at 05:24 AM, Matthias Klose wrote:
>
> >So, Barry's [CCed] concern was that an upstream build without any options
> >would include /usr/local/lib/python2.7/site-packages, which was used by
> >debian policy as well. Therefore the debian system build now uses
> >dist-packages for /usr and /usr/local. Otoh, it's most likely that you do
> >want to use the system packages for everything else, e.g. when building
> >library bindings.
>
> Historically[1], a from-source build of Python using the default configure,
> would install Python into /usr/local/bin, with
> /usr/local/lib/pythonX.Y/site-packages being where third party modules got
> installed.
>
> Debian's interpretation of the FHS allows system owners to install third party
> software outside of the packaging system to install Python modules into
> /usr/local/lib/pythonX.Y/site-packages, and for those to be visible to the
> system Python. Thus we have a clash, because if I install Python from source
> and some third party modules (e.g. for isolation from the system Python), I
> could potentially break my system Python. Worse, it might work on Solaris and
> Gentoo, but break on Debian and Ubuntu.
>
> The solution (many years field tested by now) was the switch to dist-packages
> as the place that the Debian packaging system installs modules and putting
> /usr/local/lib/pythonX.Y/dist-packages on sys.path.
+ remove all paths including site-packages from sys.path.
> This eliminates potential conflicts between system Python and a from-source
> install.
Sure, nobody is arguing that having the system Python and from-source
Python use a different path is a bad thing (it's a good idea). But this
is not what this bug is about.
What this bug is about is what happens when I build a 3rd party module
for use with the system Python using --prefix=/usr.
In this case the modules are installed
to /usr/lib/python2.7/site-packages/ even though I built against the
system Python.
This means that the system Python doesn't see the module which I built
for it.
And in fact this module, built against the system Python is in a place
where a from-source install would find it -- which reintroduces the
original potential for breakage that dist-packages was introduced to
fix, doesn't it?
> My suggestion for upstream Xen would be to amend its build command line to
> something like this:
>
> $(PYTHON) setup.py install --prefix=$(PREFIX) $(INSTALL_LAYOUT)
>
> Normally $INSTALL_LAYOUT would be empty so people doing Xen builds from source
> would just get whatever behavior is typical for the Python they're using. The
> Debian packager would then define INSTALL_LAYOUT='--install-layout=deb' and it
> would Just Work.
This is what we do today.
The Debian packages can and do do the correct thing, they are not the
problem here.
> Then, if Xen users wanted to install Xen from source into their system
> Python[2] they would have to either provide the $INSTALL_LAYOUT value, or add
> /usr/local/lib/pythonX.Y/site-packages to their sys.path manually.
Installing a 3rd party module from source against the system Python
should Just Work. There is no reason for it not to. It's totally
unreasonable to expect users to have to manually munge sys.path or set
magic environment variables.
> [2] Which I personally think is a bit suspect since IMHO only Debian packages
> should be used with the system Python
I wholeheartedly disagree with this. It is entirely reasonable for users
to want to use a simple 3rd party module with the system Python without
having to rebuild the whole Python system (including all the modules
they use which *are* in Debian) from source.
> - and why not use virtualenv or a
> from-source build of Python?
It is unreasonable to expect users to have to build Python from source
just to do a build of a newer version of Xen (or any other python
module) than is packaged in Debian.
Ian.
--
Ian Campbell
Murray's Rule:
Any country with "democratic" in the title isn't.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
