Re: python 2.2 -> python 2.3 transition
On Wed, 2003-08-13 at 23:33, John Goerzen wrote:
> On Wed, Aug 13, 2003 at 02:14:55PM +1000, Donovan Baarda wrote:
> > > Actually, all that have that are now uninstallable. Some important ones
> > > have that, such as libwxgtk2.4-python.
> > >
> > > Shouldn't they depend on python2.2 instead
> >
> > No. There is a reason they are not installable... they don't work with
> > python (2.3)
>
> But they do with Python 2.2... why not let them at least be installable with
> that version?
Because the package maintainer chose not to. Maybe he/she is regretting
that now :-)
I personally agree that anyone producing python extension modules should
be using the pythonX.Y-foo + python-foo wrapper approach. This would
mean their old pythonX.Y-foo packages would still work during and after
a python transition. You get "legacy support" for free.
However, the Policy does give them the option not to, and there could be
valid reasons not to do so for some cases.
> As an example, in OfflineIMAP, I write:
>
> Depends: python2.2, python2.2-twisted, python2.2-pyopenssl
> Suggests: python2.2-tk
>
> (Yes this differs slightly from what's in the archive; it's from my svn
> repository).
This is a package that supports python2.2 then... that's fine. However,
it doesn't guarantee that it can be used with python (X.Y), and in-fact
it wont for python (2.3).
> Now, I could do the dependency on python (>= 2.2), python (<<2.3) thing.
> But what would that gain me or users? I see no benefit there, other than
> people tracking sid would find OfflineIMAP uninstallable until it gets
> updated to depend on Python 2.3.
Yep... that's the advantage :-) you can't install it if it wont work.
This also means it won't propagate into "testing" if it doesn't work.
> > Fortunately, most "python-foo" packages are simple wrappers that have
> > "Depends: python2.2-foo", so they are very small and easy to "fix" for
> > python (2.3) (changed to "Depends: python2.3-foo").
>
> That makes a lot of sense to me, and I have no quibble with that approach.
> If libwxgtk2.4-python took that approach, I'd have no complaints as I could
> still install and use the lib under Python 2.2. As it is, that is
> impossible, even though the lib remains compatible with Python 2.2.
You can file a wishlist bug against libwxgtk2.4-python requesting that
it use that approach if you like. I would if it annoyed me :-)
However, you might get the response "this is only a temporary problem
during the transition to python (2.3). It will be fixed when I produce a
new libwxgtk2.4-python that depends on python (2.3)".
The reality is during a transition like this, packages will be broken.
The Python Policy was designed so that these broken packages are
identified and can't be installed.
Note that libwxgtk2.4-python _does_ work with python (2.2). You can
always install python (2.2) from testing and it will all work. Note that
python in testing will never be broken like this. The dependencies
ensure that testing can only transition to python (2.3) when everything
works.
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: