On Sun, 2006-06-04 at 23:05 +0200, Raphael Hertzog wrote: > On Sun, 04 Jun 2006, Joe Wreschnig wrote: > > On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote: > > > Hello, > > > > > > now you know a bit better the policy (or at least the generic idea, feel > > > free to discuss details further), > > > > No. After the previous thread I am still in the dark on: > > - Tight upper dependencies. We you just incorrect, or are they > > actually required? > > For extensions they are required. For arch:all modules they're not > required since python-support / python-central can make them instantly > available to a new python version. > > > - python2.x-* packages -- are they needed? desirable? > > Steve and Matthias gave different answers, and if they're present > > migrations end up just as fragile as they are now. > > There's only python2.X-* _virtual_ packages. They are desirable but not > needed unless a python application which doesn't use the default python version > requires a specific python-version of a module. > > However I don't see the problem of providing systematically python2.X-foo > (in particular for extensions). > > > Until these two issues are clear, everything else is irrelevant. The > > goal shouldn't be to pick a tool, but to solve the problem. If neither > > Which problem? The problem that Python migrations are currently very fragile due to strict dependencies and interconnectedness of many modules. I'm finally beginning to piece together the conclusions of the BoF, but there were many missing details (and any other onlookers are probably even more confused than me). It's very difficult to discuss this without a clear statement of what policies were decided there, since all emails so far have only discussed part of the issue, or been vague. It's hard to gauge whether python-support or python-central is more appropriate for the new policy without a clear statement of what that policy is. So here's *my* attempt at summarizing the BoF, based on your first mail and responses, and independent of the tools used: 1) Public modules and extensions should support all available Python versions, using a single binary package. 2) A new control field, XC-Python-Version will be used to determine what versions of Python a module supports. 3) The tight upper bound on module dependencies will be removed, provided the module actually works on future versions of Python. The upper bound on extension dependencies will not, because then they wouldn't work. 4) python2.x-* virtual packages are to be used only when necessary, but packages can provide them regardless. 5) Private modules and applications should use some way to support more than one Python version, if possible. Is this accurate? 1), 3), and 4) contridict your original email, but match what you told me this time. 4) I am still unsure of, because Steve and Matthias gave different answers, and your answer is confusing -- if they're desirable, let's make them required; if not, let's not pollute the (virtual) package namespace unless we need them for a specific reason. 2) is suspect. It's not required for multiversion support *in policy*. The working python-support implementation in unstable, while still lacking such fields, proves that. I feel it's much more of an implementation issue than a policy one, and so if we don't use python-central (which I gather is the impetus for it), we shouldn't bother with the control field either. -- Joe Wreschnig <piman@sacredchao.net>
Attachment:
signature.asc
Description: This is a digitally signed message part