Am 19.11.2012 18:10, schrieb Ian Campbell:
> Package: python2.7
> Version: 2.7.3~rc2-2.1
> Severity: normal
>
> The Xen build system contains some python modules which it installs
> with:
> $(PYTHON) setup.py build
> $(PYTHON) setup.py install --prefix=$(PREFIX) --force
>
> Where $(PREFIX) is by default "/usr", $(PYTHON) is just "python" and
> setup.py uses distutils.
>
> This results in the python files being installed in
> /usr/lib/python2.7/site-packages/ which is not present in sys.path.
yes, this is expected. the rationale for this is that it is too easy to
overwrite things shipped using the distro packaging.
> Removing the --prefix=$(PREFIX) results in installation into
> /usr/local/lib/python2.7/dist-packages/ which is in the sys.path (so
> correct in that sense) but doing this in the Xen tree removes the
> option for people to install Xen to an alternate prefix (e.g. I think
> NetBSD uses --prefix=/usr/pkg or some such).
>
> As a workaround one can use "--prefix=$(PREFIX) --install-layout=deb"
> but it seems wrong to require end users building stuff from source on
> their systems (as opposed to packagers) to know about and use
> this. We (Xen.org upstream) have a steady stream of bug reports from
> users whose modules have ended up outside of sys.path in this way.
If xen does work, when found in /usr/local/lib/python2.7/dist-packages, then I
would prefer that this location is used by the default upstream configuration.
If this is make based, maybe use something like
$(if $(wildcard /etc_debian_version),,--prefix=$(PREFIX))
maybe this has to be conditionalized for a specific PREFIX value as well.
> Also the debian/changelog for 2.6.1-3 says "The options
> --install-layout=deb and --prefix are exclusive." (I think this meant
> to say "mutually exclusive"?) so I don't think this is intentionally
> supported (this is what we actually recommend in practice, but we'd
> rather not).
probably, I'm not a native speaker. Maybe I did change it to work around some
build failures. For distro builds dh_python2 does a good job to work around
these.
> Something similar was discussed in #LP362570 but I think this case is
> sligthly different, this is a python module being built from source by
> the end use against the system/distro python rather than against a
> custom installed python in /usr/local.
>
> Changing unix_prefix to use dist- instead of site-packages would fix
> this issue, I think.
the default would be still unix_local. how would you make sure that unix_prefix
is selected without being the default option?
> There seems to be concern about modules built for the system- vs
> custom-python clashing with each other. My expecation would be that if
> you were building against a custom python then you would be using the
> version of distutils supplied by that python (e.g. running
> /my/custom/python setup.py not /usr/bin/python ...), which would be
> using site-packages as expected. Therefore changing the system
> installed distutils to use the right path for the system installed
> python seems correct.
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.
Yes, I would expect that using a custom python uses it's included distutils,
however I can't see how it would not with the current packaging of the system
python.
Matthias
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
