On 30/11/12 10:27, Ian Campbell wrote:
On Fri, 2012-11-30 at 05:24 +0100, Matthias Klose wrote:
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.
But that's effectively what the command is explicitly asking for, isn't
it? Xen *wants* to install things in the distro python's system path.
Matthias,
It sounds a bit like you're trying to have setup.py "prevent the user
from doing this for her own good". IMHO that's not good software
design, especially if we're talking about developers. The default
should be something sensible that doesn't clobber things; but if the
user starts specifying things, she should be allowed the power to shoot
herself in the foot if she wants.
The default, if --prefix is not specified, is to install in
/usr/local/lib/.../dist-packages, which is safe; so for other settings,
we should trust that the user knows what she's doing (and allow her to
suffer the consequences if she doesn't).
-George
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,
I haven't tried but I expect it does.
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))
That's a pretty gross hack to ask upstream to carry.
It also breaks for anyone building on Debian who wants to install to
their own prefix (/opt/xenX.Y or something).
maybe this has to be conditionalized for a specific PREFIX value as well.
I think it would need to be, which just makes it more gross.
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?
That's what passing --prefix=PREFIX (where PREFIX!=/usr/local) does,
isn't it? You would hit the first case ("elif (self.prefix_option ...")
in this, not the second, wouldn't you?
+ elif (self.prefix_option and
os.path.normpath(self.prefix) != '/usr/local') \
+ or 'PYTHONUSERBASE' in os.environ \
+ or 'real_prefix' in sys.__dict__:
+ self.select_scheme("unix_prefix")
+ else:
+ if os.path.normpath(self.prefix) == '/usr/local':
+ self.select_scheme("deb_system")
+ else:
+ self.select_scheme("unix_local")
If PREFIX=/usr/local then the distinction between unix_local and
unix_prefix (as modified by my suggestion) goes away so it doesn't
really matter which one you pick.
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.
I'm not sure what you are trying to say here.
If you are building library bindings for the system python then you
would use the system python to do so, which picks up the patched
distutils and installs in the correct dist-packages based location.
If you are building library bindings for a custom python then you would
use the custom python to do so, which picks up the unpatched distutils
and installs in the correct site-packages based location.
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.
That sounds right, you don't want the custom python picking up the
system pythons distutils. That would be madness and would lead to things
being installed in the wrong places.
BTW, why is this Debian specific? Don't all these arguments about
system-python vs. custom-python apply to all distros? Or is this stuff
going to happen upstream too?
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
