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.
> > 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.
--
Ian Campbell
Current Noise: Motörhead - Stay Clean
Of course there's no reason for it, it's just our policy.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
