On Thu, 23 May 2002, [EMAIL PROTECTED] (Donovan Baarda) wrote: > if I understand it, foo is not really a 'binary' but an 'executable > script'... (which means it can be Python version independant).
Yep. > This situation is identical to the existing idle package. It's worth looking > at how it handles it. I'll take a look, thanks. > 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. > 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 ;-) > 1b) as 1), but also provide foo symlink using Debian alternatives. Like I said, this is very high maintainence -- in real life, scripts are added to upstream package frequently, and I don't want to echo this in my postinst/prerm > 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. > 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. > 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 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. 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)' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]