Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit : > > If we don't, I don't see the purpose of the policy alltogether. > > Allowing transitions between default versions of python without package > renames, bypassing NEW, allowing binNMUable transitions, and generally > simplifying the python upgrade path for users across releases. How does the broken "current" semantics help with any of these goals? > Supporting multiple binary extensions in a single python-foo package is a > tool that *facilitates* that goal, but it was *never* supposed to be > mandatory. There are extensions with no/few reverse-dependencies and a > small install base, such that supporting multiple versions of python is > useless archive bloat. This has absolutely nothing to do with what we are discussing. The decision to build for one or all python versions belongs to the maintainer, and the build process should reflect it. But by expressing "current" instead of the real list of supported python versions, you completely lose track of which python versions are actually supported by the source package. > Evidently everyone has lost sight of this as a result of Josselin's process > hijacking. Oh well. I'm interested to know which process I have hijacked. I have not contributed to python policy changes since the "new policy" madness has started, and I haven't forced anyone to implement things. I've just implemented a tool that does things *correctly* and helps other maintainers in this maelstrom of incorrect documentation and blurry packaging processes. Or maybe you're saying that just because it's easier to point someone as the sole responsible for the current fiasco than to find real, working solutions. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=