On Thu, May 23, 2002 at 04:34:18AM -0000, Moshe Zadka wrote: > On Thu, 23 May 2002, [EMAIL PROTECTED] (Donovan Baarda) wrote: [...] > > This situation is identical to the existing idle package. It's worth looking > > at how it handles it. > > I'll take a look, thanks.
Note the naming convention 'pythonX.Y-foo' for the module and 'foo-pythonX.Y' for the executable were taken strait from the idle package example. I use this convention thoughout my discussions. > > 1) have foo.py support python2.1, python2.2, provide foo-python2.1 using > > python2.1 and foo-python2.2 using python2.2. > > > > make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2), > > foo-python2.1 (Depends: python2.1, python2.1-foo) with > > /usr/bin/foo-python2.1 using '#!/usr/bin/python2.1', foo-python2.2 (Depends: > > python2.2, python2.2-foo) with /usr/bin/foo-python2.2 using > > '#!/usr/bin/python2.2'. > > except there is no way to install something at "/usr/bin/foo". Users should > not *have* to care about python versions. That is the limitation of 1), addressed by 1a) and 1b) below. > > 1a) as 1), but also provide foo symlink for python (default). > > this makes sense....I can just put the symlink in python2.1-foo-bin and > move the symlinks when a python default change. > > > as 1), but also make foo (Depends: python (>=2.1), python (<<2.2), > > foo-python2.1) with symlink /usr/bin/foo to /usr/bin/foo-python2.2 > > so that if I go MIA I'm keeping python back? ugh ;-) You will not be holding python back... when python upgrades your 'foo' package will become incompatible and end users will be forced to make the decision "upgrade to python (2.2), or keep foo". Note that the foo-python2.1 and foo-python2.2 packages will still be OK. If your 'foo' never gets updated, it should be dropped from the archive as any old incompatible packages should. There is a reason why the dependancies are structured this way... they say 'this package depends on the default python being installed, where the default python is 2.1'. When the default python changes, this condition is not met, and hence you package cannot be installed untill it is upgraded to match the new python. [...] > > The 1) options all force developers using foo.py to choose between 2.1 and > > 2.2. > > I don't think I mind that. developers can either support both or support > just one, and change which one they're supporting when they want to. But the point is they can't choose to "support the default python". They are forced to tie their own scripts/modules to a particular version of python, and cannot take advantage of the way the policy can transperantly update the default python to 2.2. I really doubt that you will need to allow end users to choose which python version to use when running /usr/bin/foo script. Sure, developers will need the flexibility of using both python versions when using the foo.py module, but when it comes to running 'foo', the default python would be sufficient. For those that _really_ want to run foo with python2.2, they can run 'foo-python2.2' instead. I think using 'alternatives' is overkill for this reason, and the symlink is a good idea. > > 2) have foo.py support python2.1, python2.2, python (default), provide foo > > using python (default). > > > > make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2), > > python-foo (Depends: python (>=1.1),python (<<2.2), python2.1-foo) wrapper, > > foo (Depends: python, python-foo) with /usr/bin/foo using > > '#!/usr/bin/python'. > > Except that again, my package is holding up a default python change. See above. The python-foo package provides support for the default version of python. There is no way around it... packages providing support for the default version of python will need to be updated when the default version of python is updated. However, since this is just a wrapper package with nothing in it, anyone could NMU it by updating its dependancies. Consider this; if you go MIA and the default python upgrades, is it better to have your package silently broken, or for the dependancies to indicate that it is broken? > > 3) use python-central to have foo.py support python2.1, python2.2, python > > (default), provide foo using python (default) > > AIUI python-central is still not there yet, correct? A lot of people are > already needing both 2.1 and 2.2 support, so I'll make do and when p-c > comes along, I'll see if I want to switch to it. python-central is currently a package in need of testing :-) get it at; http://people.debian.org/~calvin/python-central/ For python-central to fully work, the pythonX.Y packages need to use it so that modules are automaticly added when a new pythonX.Y is installed. However, without pythonX.Y support, python-central will still work fine when modules that use it are installed. > > python-central is not part of the policy yet, and probably will not be in > > woody. > > woody is irrelevant -- I wouldn't make such changes in woody. > > I'm thinking of doing 1a above -- people who don't give a damn won't care > about the versions and people who do can run "foo2.2" for all I care. > > In short: installing python2.1-foo will have foo.py, /usr/bin/foo2.1 and > a foo->foo2.1 symlink. installing python2.2-foo will have foo.py, > /usr/bin/foo2.2 and no symlink. I'll create the symlink in d/r based on > the default python version on the build system, so rebuilding after python2.2 > is default will cause the symlink to move from python2.1-foo to > python2.2-foo. it will also cause the dummy package python-foo to move from > depending on python2.1-foo to depending on python2.2-foo. I assume the 'dummy package python-foo' will be in the form of a "Provides: python-foo". The problem with this is your dependancies will not "break" the package when python upgrades, unless you have python2.1-foo with "Depends: python (>=2.1), python (<<2.2), python2.1". You are starting down untested ground if you go this way and have a package that is non-policy compliant. I would recommend the following; python2.1-foo (Depends: python2.1) has /usr/lib/python2.1/site-packages/foo.py and /usr/bin/foo-python2.1 with '#!/usr/bin/python2.1' python2.2-foo (Depends: python2.2) has /usr/lib/python2.2/site-packages/foo.py and /usr/bin/foo-python2.2 with '#!/usr/bin/python2.2' python-foo (Depends: python (>=2.1), python (<<2.2), python2.1-foo) has symlink /usr/bin/foo to /usr/bin/foo-python2.1. This allows developers to choose python2.1, python2.2 or python (default). Sure, when you go MIA and python (default) upgrades, the python-foo package will break, but there is no way around this when you provide support for python (default). Remember that python-foo is a very simple wrapper package that anyone could NMU, particularly if you have the d/r sorting it all out for you. > Unless anyone sees any problem with it, here is what I will use to find out > the default python on the build system: > /usr/bin/python -c 'import sys;v=sys.hexversion;print "%s.%s" % > ((v>>24)&0xff, (v>>16)&0xff)' The trick of finding the default python in d/r is a neat idea. I'm not sure of all the implications of this, but you could certainly use this to auto-build the python-foo dependancies and symlink(s). Perhaps this could become part of the python-policy? I believe some work is going to happen soon on python-policy support in debhelper. If you really, really, _really_, are concerned about python-foo 'holding back' python and don't want to support the default python, then you could use my suggested plan, but omit the python-foo package and provide the /usr/bin/foo symlink in python2.1-foo. If you do this, _DO NOT_ use any sort of "Provides: python-foo", as 'python-foo' should indicate support for the default python, and without the 'python-foo' package, you are not providing true default python support. -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
