bokeh's setup.py contains: if exists(bokeh_path) and isdir(bokeh_path): val = raw_input("found existing bokeh install, remove it?[y|N]") if val == "y": print ("removing old bokeh install") shutil.rmtree(bokeh_path) print ("not removing old bokeh install") which is broken, first, because there is no raw_input in Python3 and second, because it's insane to ask questions when emerge is running. So the ebuild has to remove these lines from setup.py
"ebuild is broken" - how, precisely?
(In reply to Jeroen Roovers from comment #1) > "ebuild is broken" - how, precisely? As I said, the ebuild has to patch the setup.py file, e.g., by removing the cited lines above. (If emerge (in this case a 2nd emerge) fails due to a Python error, then I call the ebuild erroneous)
Yeah, seems to be a problem introduced in 0.5.0.
(In reply to Helmut Jarausch from comment #2) > (In reply to Jeroen Roovers from comment #1) > > "ebuild is broken" - how, precisely? > > As I said, the ebuild has to patch the setup.py file, e.g., by removing the > cited lines above. > > (If emerge (in this case a 2nd emerge) fails due to a Python error, > then I call the ebuild erroneous) To claim "has to" is a bold call, though perhaps justified. On my part I am less inclined to rush to such a concluded stance. This is the first and only instance of this I've seen making for a lack of any precedent as to how to manage it. Unmerging the installed instance allowed it to proceed, making a merge it achievable although under a most undesirable demand. This is invoked by upstream who seemingly at whim decided to throw in this work flow. While patching out those lines will be effective, is there some consensus that this is a 'good fix'. It's customary to submit it to upstream however in this instance it's a case of calling his new work flow that he explicitly elected to add as bad and please scrap it. I'd tend to just sed or patch it out and save us the possibility of having him think us silly or impertinent. There is a latest release of bokeh 0.6.1. The additions to that were even worse to the point that I abandoned bumping it to portage at all and settled for this 0.5.0. In summary, this package is quite exceptional.
The 'has to' only refers to the fact that an interactive installation procedure doesn't fit into the context of Gentoo. (At least) current versions of portage decide itself to reemerge packges if it deemed to be necessary. Furthermore, python-updater would reemerge this package. And it would be more than surprising to a casual user if this fails.
(In reply to Ian Delaney from comment #4) Those lines were added to setup.py by somebody (upstream) who does not understand how package management systems work. They want to make sure that any installed instance is uninstalled before an upgrade occurs. In an ebuild environment, we do not need to worry about that since we install to a staging area (${D}) and we let portage worry about merging/unmerging the files appropriately. The reporter's suggested fix (removing or disabling the lines in setup.py) is correct, at least in the case of installation using a package manager.
(In reply to Mike Gilbert from comment #6) > (In reply to Ian Delaney from comment #4) > > Those lines were added to setup.py by somebody (upstream) who does not > understand how package management systems work. apparently > They want to make sure that > any installed instance is uninstalled before an upgrade occurs. > which sets us a merry dance. It also supports my description that he set it to that style at a whim. > In an ebuild environment, we do not need to worry about that since we > install to a staging area (${D}) and we let portage worry about > merging/unmerging the files appropriately. > That we (devs) know > The reporter's suggested fix (removing or disabling the lines in setup.py) > is correct, at least in the case of installation using a package manager. which amounts to unconditional support to the notion of removing them, with which I don't disagree. This achieves a consensus adequate to purge them. 30 Oct 2014; Ian Delaney <idella4@gentoo.org> +files/0.5.0-setup.patch, bokeh-0.5.0.ebuild: add patch to purge check for previous install from setup.py, fixes Bug #527336 And it's noteworthy that those lines are absent in the not to be added (by me) blaze-0.6.1 suggesting someone else criticised it or he figured it a bad idea himself.