Quoting Anthony Towns <aj@azure.humbug.org.au>: > On Thu, Nov 01, 2001 at 11:38:57AM +1100, Donovan Baarda wrote: > > Note that additionaly all packages that depend on plucker _and_ python > must > > use "Depends: plucker, python2.1" and _not_ "Depends: plucker, python > (>= 2.1), > > python (<<2.2)". > > Uh, no, they should *not* do that. Consider what happens when we move > to python2.2 (or 2.3 or whatever) and plucker starts only working with > python2.3 (apt will dist-upgrade to the new plucker, old scripts will > keep > referring to python2.1 and plucker, and since plucker only works on 2.2, > they'll all break).
Hmm, a problem. I didn't think of that. But there is also a problem when python upgrades to python (2.2) and plucker is not upgraded and hence stays in /usr/lib/python2.1. Anything that uses #!/usr/bin/python and plucker will fail. This is a risk to be wary of with "Option 2" packaging... you package <foo> for a particular version of Python, and that ties any other packages that depend on <foo> to that particular version of python. This is what I was trying to make clear with my advice above. Unfortunately, if you _don't_ choose the recomended pythonX.Y-<foo> naming convention, you have no way of notifying any packages that depend on <foo> that an upgrade has made <foo> now depend on a different version of Python (unless they all strictly use some versioned depends scheme). Of course, if the dependant packages just depend on <foo>, this is not an issue, as <foo> itself will depend on the appropriate version of python. > Either Depend: on "python, plucker" (with versions as appropriate) and > use #!/usr/bin/python (or /usr/bin/env python) or Depend: on "pythonX.Y, > pluckerX.Y" and use #!/usr/bin/pythonX.Y. The latter is probably not a > useful thing to do in general. This is good advise. However, in the case of plucker, I think he can get away with something else. It sounds like anything that uses plucker shouldn't even know that it uses Python... it's strictly a Python application. This means anything that depends on plucker will not be using Python to import anything from it. This means plucker can safely depend on pythonX.Y without using the pluckerX.Y naming scheme. -- ABO: finger [EMAIL PROTECTED] for more information.