Bug #9242
closed[Deployment] python-six backport breaks other users
Description
The arvados supplied python-six deb (1.10.0-1) is a newer version than the stock ubuntu 14.04 version (1.5.2-1ubuntu1), so replaces it. The version supplied by ubuntu installs to /usr/lib/python2.7/dist-packages/ as expected, but the arvados version installs to /usr/local/lib/python2.7/dist-packages.
The stock ubuntu python-scipy package contains a symbolic link as follows:
/usr/lib/python2.7/dist-packages/scipy/lib/six.py -> ../../six.py
With the stock python-six installed this is fine, but of course with the arvados version this symlink is broken.
Current thinking is that the best way to fix this is to have our backport install its files to /usr/lib instead of /usr/local/lib. If we want it to act as a drop-in replacement package, it should maintain as much compatibility as possible, including having files in the original locations.
Files
Updated by Brett Smith over 8 years ago
- Status changed from New to In Progress
- Assigned To set to Brett Smith
- Target version set to 2016-05-25 sprint
Updated by Brett Smith over 8 years ago
- File pkgtest.log.xz pkgtest.log.xz added
Brett Smith wrote:
Current thinking is that the best way to fix this is to have our backport install its files to /usr/lib instead of /usr/local/lib. If we want it to act as a drop-in replacement package, it should maintain as much compatibility as possible, including having files in the original locations.
9242-python-backport-prefix-wip is up for review to implement this. I have built and tested the packages on all targets. See the attached test log.
Updated by Brett Smith over 8 years ago
- Target version changed from 2016-05-25 sprint to 2016-06-08 sprint
Updated by Ward Vandewege over 8 years ago
reviewing 9242-python-backport-prefix-wip: LGTM. Thanks for the various cleanups.
Updated by Brett Smith over 8 years ago
Ward Vandewege wrote:
reviewing 9242-python-backport-prefix-wip: LGTM. Thanks for the various cleanups.
Dealing with a merge conflict, I realized I had a bug: I took the --iteration
switch out of a few lines, not realizing that they were calling fpm
directly instead of fpm_build
.
I have rebased the branch on master, and updated those lines to use fpm_build
, so they'll continue to benefit from smarts that we add there. Now at 970fab5. The only lines that are changed relative to the previous review is the hunk referring to schema_salad et al.
Updated by Ward Vandewege over 8 years ago
Brett Smith wrote:
Ward Vandewege wrote:
reviewing 9242-python-backport-prefix-wip: LGTM. Thanks for teh various cleanups.
Dealing with a merge conflict, I realized I had a bug: I took the
--iteration
switch out of a few lines, not realizing that they were callingfpm
directly instead offpm_build
.
Oh! I thought that was on purpose, since they were superfluous (--iteration 1
).
I have rebased the branch on master, and updated those lines to use
fpm_build
, so they'll continue to benefit from smarts that we add there. Now at 970fab5. The only lines that are changed relative to the previous review is the hunk referring to schema_salad et al.
Very nice. Great improvement. You can drop the --verbose --log info
from the rdflib-jsonld build line, there's no reason for that. Of course this now bumps the iteration to 2 for the schema_salad, ruamel.yaml, cwltool and rdflib-jsonld builds, for no real reason. Maybe add --iteration 1 to those lines?
Otherwise, LGTM!
Updated by Brett Smith over 8 years ago
Ward Vandewege wrote:
Brett Smith wrote:
Dealing with a merge conflict, I realized I had a bug: I took the
--iteration
switch out of a few lines, not realizing that they were callingfpm
directly instead offpm_build
.Oh! I thought that was on purpose, since they were superfluous (
--iteration 1
).
That's not superfluous: if you run fpm without any --iteration
, you get a package with no iteration, which is different than a package with iteration 1. But the reason I took them out is because my intent was to let fpm_build
set the iteration. Like I said, I thought they were fpm_build
lines, and now they are.
I have rebased the branch on master, and updated those lines to use
fpm_build
, so they'll continue to benefit from smarts that we add there. Now at 970fab5. The only lines that are changed relative to the previous review is the hunk referring to schema_salad et al.Very nice. Great improvement. You can drop the
--verbose --log info
from the rdflib-jsonld build line, there's no reason for that.
Done in 5520e6c.
Of course this now bumps the iteration to 2 for the schema_salad, ruamel.yaml, cwltool and rdflib-jsonld builds, for no real reason.
There is a real reason: all the files have moved around inside the package. (This is the functional reason to switch to fpm_build
: so the packages use distro-like paths instead of /usr/local
.) Since there's a non-functional package change, bumping the iteration is the right thing to do.
Thanks.
Updated by Ward Vandewege over 8 years ago
Brett Smith wrote:
Ward Vandewege wrote:
Brett Smith wrote:
Dealing with a merge conflict, I realized I had a bug: I took the
--iteration
switch out of a few lines, not realizing that they were callingfpm
directly instead offpm_build
.Oh! I thought that was on purpose, since they were superfluous (
--iteration 1
).That's not superfluous: if you run fpm without any
--iteration
, you get a package with no iteration, which is different than a package with iteration 1. But the reason I took them out is because my intent was to letfpm_build
set the iteration. Like I said, I thought they werefpm_build
lines, and now they are.I have rebased the branch on master, and updated those lines to use
fpm_build
, so they'll continue to benefit from smarts that we add there. Now at 970fab5. The only lines that are changed relative to the previous review is the hunk referring to schema_salad et al.Very nice. Great improvement. You can drop the
--verbose --log info
from the rdflib-jsonld build line, there's no reason for that.Done in 5520e6c.
Of course this now bumps the iteration to 2 for the schema_salad, ruamel.yaml, cwltool and rdflib-jsonld builds, for no real reason.
There is a real reason: all the files have moved around inside the package. (This is the functional reason to switch to
fpm_build
: so the packages use distro-like paths instead of/usr/local
.) Since there's a non-functional package change, bumping the iteration is the right thing to do.Thanks.
OK makes sense. LGTM.
Updated by Brett Smith over 8 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:ae72b172c8bf8a52358a89f8a8d744ec5bf2d993.