Summary: | games-fps/doomsday: relies on python wrapping internals | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | [OLD] Games | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | QA | CC: | games |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 484398 |
Description
Michał Górny
2013-09-09 21:49:39 UTC
How is that a bug? (In reply to Julian Ospald (hasufell) from comment #1) > How is that a bug? It's touching internals. Things you aren't supposed to touch nor rely on. We're likely going to break it in a few days or weeks from now. What kind of internals? I don't use internal functions. You're making assumption about how will wrapping work. You're only guaranteed that 'launch-doomsday' will be accessible where you want it, and that it will respect implementation choices. You are not allowed to assume about location of wrapped scripts. If you mess with your API, you have to fix the consumers. If you break this package by eclass changes, I will revert it to the old python eclass. (In reply to Michał Górny from comment #4) Instead of framing it as people doing something wrong and using eclass internals, you could simply state that the eclass behavior may change soon. No need to put people on the defensive. End of the day, we are all just trying to make stuff work with the tools we are given. FYI: I've forced python-exec:0 in the ebuild now. We will probably revisit this near python-exec:2 going stable, so please keep the bug open. Made it compatible with python-exec:2. |