Bug #9242
closed
[Deployment] python-six backport breaks other users
Added by Brett Smith over 8 years ago.
Updated over 8 years ago.
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
- Status changed from New to In Progress
- Assigned To set to Brett Smith
- Target version set to 2016-05-25 sprint
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.
- Target version changed from 2016-05-25 sprint to 2016-06-08 sprint
reviewing 9242-python-backport-prefix-wip: LGTM. Thanks for the various cleanups.
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.
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 calling fpm directly instead of fpm_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!
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 calling fpm directly instead of fpm_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.
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 calling fpm directly instead of fpm_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.
OK makes sense. LGTM.
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:ae72b172c8bf8a52358a89f8a8d744ec5bf2d993.
Also available in: Atom
PDF
Updated by 
Updated by