Created attachment 362118 [details, diff] pysolfc-python-exec-2.patch main.py uses argv[0] in a couple of places. With python-exec:1 it was "/usr/share/games/pysolfc/pysol.py", but with python-exec:2 it is "/usr/lib/python-exec/python2.7/pysol.py". pysolfc tries to find its files in /usr/lib/python-exec/python2.7/ and, naturally, fails: OSError: /usr/lib/python-exec/python2.7/pysol.py: DataLoader could not find ('html/license.html',) The attached patch fixes this failure by hardwiring "/usr/share/games/pysolfc/pysol.py" instead of argv[0]. It fixes the problem, though, maybe, not in the most elegant way.
I believe this should be fixed in python-exec, not randomly in packages.
I don't think this is solvable in python-exec:2 without compromising its design goals. We have 2 conflicting goals: 1. python-exec:2 is designed to keep basename(sys.argv[0]) consistent for compatibility with "multicall" python scripts. 2. pysolfc uses dirname(sys.argv[0]) as a reference point for loading data files. I honestly don't see a way to meet both goals. If you have some idea, I would be happy to hear it. Just a thought: This particular application seems like a good fit for python-single-r1. I'm sure it can be made to work again with python-exec / python-r1, but to what purpose?
Maybe we could optionally restore python-exec:0 behavior in the eclasses. Would that be acceptable to you?
Note that I would really prefer not to do that if an alternate solution can be implemented. If you are not willing to work with us, I'll just go back to ignoring this bug.
(In reply to Mike Gilbert from comment #3) > Maybe we could optionally restore python-exec:0 behavior in the eclasses. > Would that be acceptable to you? There's still a backwards compat. It was described in the announcement [1], and games@ already had a bug where it was used [2]. [1]:http://article.gmane.org/gmane.linux.gentoo.devel/88175 [2]:https://bugs.gentoo.org/show_bug.cgi?id=484424
(In reply to Mike Gilbert from comment #4) > If you are not willing to work with us, I'll just go back to ignoring this > bug. I'm not sure what that means. Breaking other peoples ebuilds and expecting them to add hacks to their ebuilds in order to avoid that breakage does not seem right to me. I'd rather expect you to fix this. The attached patch from grozin is not appropriate and will break games variables. If an eclass keeps causing trouble for me, I will just not use it anymore.
(In reply to Julian Ospald (hasufell) from comment #6) > I'm not sure what that means. Breaking other peoples ebuilds and expecting > them to add hacks to their ebuilds in order to avoid that breakage does not > seem right to me. > The vast majority of packages are unaffected by this change. I'm sorry that it broke a couple of your packages. This is a very specific case that we need to work around, and it makes more sense to implement some small changes here than to hack around it in the eclass. I proposed a solution in comment 2 (using python-single-r1), but you have not responded to that. Alternatively, you could opt to force python-exec:0 as per the instructions in mgorny's message. > I'd rather expect you to fix this. The attached patch from grozin is not appropriate and will break games variables. If you would like me to commit either of the above solutions, just let me know. > If an eclass keeps causing trouble for me, I will just not use it anymore. If you are concerned about changes that occur in the python eclasses, I would suggest that you get more involved. I think they are getting closer to "maturity". We have a mailing list where every patch is posted for review at least a few days before committing. We really could use some additional help with testing. #gentoo-python also has some interesting discussions. I suppose we could start cross-posting gentoo-dev, but I'm not sure the wider dev community would really care.
(In reply to Mike Gilbert from comment #7) > (In reply to Julian Ospald (hasufell) from comment #6) > > I'm not sure what that means. Breaking other peoples ebuilds and expecting > > them to add hacks to their ebuilds in order to avoid that breakage does not > > seem right to me. > > > > The vast majority of packages are unaffected by this change. I'm sorry that > it broke a couple of your packages. > > This is a very specific case that we need to work around, and it makes more > sense to implement some small changes here than to hack around it in the > eclass. > > I proposed a solution in comment 2 (using python-single-r1), but you have > not responded to that. I like that eclass even less. > > Alternatively, you could opt to force python-exec:0 as per the instructions > in mgorny's message. Afais that will cause dependencies on dev-lang/python-exec:=[${PYTHON_USEDEP}] and dev-lang/python-exec:0[${PYTHON_USEDEP}] which does not make sense to me
(In reply to Julian Ospald (hasufell) from comment #8) > > I proposed a solution in comment 2 (using python-single-r1), but you have > > not responded to that. > > I like that eclass even less. > That is rather unhelpful. Is there some reason it would not be suitable for this package? > > > > Alternatively, you could opt to force python-exec:0 as per the instructions > > in mgorny's message. > > Afais that will cause dependencies on > dev-lang/python-exec:=[${PYTHON_USEDEP}] > and > dev-lang/python-exec:0[${PYTHON_USEDEP}] > > which does not make sense to me Ok, so that would indeed be an extraneous dependency. Not a huge deal, but probably something we can fix. mgorny: I think we could put the python-exec dependency behind a _python_want_python_exec2 check. Do you see any problem with that?
Created attachment 364272 [details, diff] Adjust python-exec dep based on _PYTHON_WANT_PYTHON_EXEC2 Any objections to this?
(In reply to Mike Gilbert from comment #10) > Created attachment 364272 [details, diff] [details, diff] > Adjust python-exec dep based on _PYTHON_WANT_PYTHON_EXEC2 > > Any objections to this? If you really think the lot of metadata regen is worth proper deps in a backwards compatibility hack that doesn't make any real difference, sure. Just make sure to commit it to both eclasses.
(In reply to Julian Ospald (hasufell) from comment #8) > > I proposed a solution in comment 2 (using python-single-r1), but you have > > not responded to that. > > I like that eclass even less. I'm afraid you're missing a mojor point here. Gentoo is a distribution which means a collective of people who work together. We have our QA standards and tools like eclasses. If you don't like the eclass, you have three choices. Either you: a) follow proper procedures in order to improve it, b) get along with it, c) create your own distro where you can do whatever you want and ignore whoever you like. Your choice.
(In reply to Michał Górny from comment #12) > (In reply to Julian Ospald (hasufell) from comment #8) > > > I proposed a solution in comment 2 (using python-single-r1), but you have > > > not responded to that. > > > > I like that eclass even less. > > I'm afraid you're missing a mojor point here. Gentoo is a distribution which > means a collective of people who work together. We have our QA standards and > tools like eclasses. > > If you don't like the eclass, you have three choices. Either you: > > a) follow proper procedures in order to improve it, > > b) get along with it, > > c) create your own distro where you can do whatever you want and ignore > whoever you like. > > Your choice. Yeah, you have proven a lot of QA skills with your eclasses. I stopped counting the troubles you have caused a) users and b) devs. And I don't care what you think that I am supposed to do. I am supposed to write working ebuilds not follow your obscure eclass design pattern.
+ 30 Nov 2013; Mike Gilbert <floppym@gentoo.org> python-r1.eclass, + python-single-r1.eclass: + Depend on dev-lang/python-exec:0 if _PYTHON_WANT_PYTHON_EXEC2 is 0, bug + 489646.
+ 30 Nov 2013; Julian Ospald <hasufell@gentoo.org> pysolfc-2.0-r2.ebuild: + restrict to dev-lang/python-exec:0 because dev-lang/python-exec:2 is broken + wrt #489646 NOTE: I don't consider this bug fixed. It might still randomly break other packages.
Please feel free to file additional bugs for other packages that have been broken.
