On Fri, 2006-01-13 at 11:05 +0100, Josselin Mouette wrote: > Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit : > > > - Some concerns were raised by the release team, that python-support > > > tracks it's own state instead of using the dpkg database. To keep > > > track of usable python versions, python-central uses a field > > > Python-Version in the control file (having values like "2.3, 2.4", > > > "all", ">= 2.3") > > > > Is there some reason python-support couldn't be extended to also do > > this? I agree it is a better solution than a separate database. > > I intend to make python-support use a .pyvers file listing the supported > versions. This file would be generated by dh_python, when using > dh_python -m 2.2 (for just a minimal version) or copied from > debian/$package.pyvers. > > Having a new field in the control file diverges from how debhelper > programs usually behave, so I'd like to avoid such a solution - and I > don't think there's a need for it.
Well, there is a need for a database of some kind. And I think given the nature of the information, dpkg seems a good place to keep it. Note that we're not talking about "debhelper programs" here, but all Python packages. Python policy shouldn't mandate debhelper, even if debhelper can enable packages to conform with the policy. As a maintainer, I wouldn't find it confusing or inconvenient to have another field in the control file. In fact, it would probably make it easier to update, since in what you propose Python version handling would be split between debian/control and debian/rules (as it is now); in Matthias's system, it would all be in debian/control. Which makes sense, because it's install-time package relationships, not build instructions. -- Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part