On Wed, May 22, 2002 at 04:50:02PM -0000, Moshe Zadka wrote: > On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote: > > > Ok, thats a problem. There is no way out for this; you'd have to > > have two binaries. > > Yes, I know I'll have to have two binaries.
if I understand it, foo is not really a 'binary' but an 'executable script'... (which means it can be Python version independant). This situation is identical to the existing idle package. It's worth looking at how it handles it. You have several options if you want python2.1 and python2.2 supported; 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'. 1a) as 1), but also provide foo symlink for python (default). 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 1b) as 1), but also provide foo symlink using Debian alternatives. as 1) but make packages foo-python2.1 and foo-python2.2 use Debian alternatives for /usr/bin/foo. The 1) options all force developers using foo.py to choose between 2.1 and 2.2. They cannot just depend on the default python, forcing them into cascading package updates when they change python versions. The varients simply provide different ways of making the foo script more accessable. The following alternatives allow developers to depend on the default python and minimise their package dates. 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'. This follows the policy to the letter. It allows developers to use foo.py with any of the three python versions. The python (default) is an alias for 2.1 in woody, but when the default changes to 2.2, packages that depend on the default will not need to be updated to use it. When the default becomes 2.2, you just need to release a new python-foo (Depends: python (>=2.2), python (<<2.3), python2.2-foo) wrapper package, and foo will automaticly be using python2.2. 2a) have foo.py support python2.1, python2.2, python (default), incidentaly 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) with /usr/bin/foo using '#!/usr/bin/python'. This deviates from the policy a tiny bit in that python-foo is more than just a wrapper package because it includes the /usr/bin/foo script. However, it does eliminate one extra foo package and otherwise provides all the benefits above. 3) use python-central to have foo.py support python2.1, python2.2, python (default), provide foo using python (default) make python-foo (Depends: python2.1 | python2.2, python-central), foo (Depends: python, python-foo) with /usr/bin/foo using '#!/usr/bin/python. 3a) use python-central to have foo.py support python2.1, python2.2, python (default), incidentaly provide foo using python (default) make python-foo (Depends: python, python2.1 | python2.2, python-central) with /usr/bin/foo using '#!/usr/bin/python'. python-central is not part of the policy yet, and probably will not be in woody. Using python-central would require you to put modules in /usr/lib/python/site-packages and call 'register-python-package (configure|remove) python-foo' in the postinst/prerm scripts. how you provide python-foo and foo is fairly disjoint, and you can probably mix-n-match the foo and python-foo packaging options (ie option 3 python-foo, option 1b foo), provided you carefuly think out the dependancy implications. -- ---------------------------------------------------------------------- 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]