Quoting Neil Schemenauer <[EMAIL PROTECTED]>: > Jim Penny wrote: [...] > The python is a small package to create a link from /usr/bin/python2.2 > to /usr/bin/python. python-eggs is a dummy package for dependencies > (similar to what is done for GCC). When we upgrade Python to 2.2 we > have: > > /-------------------------------------> python ---> > python-2.2 > spam -- > \---> python-eggs ---> python-eggs-2.1 -----------> > python-2.1 > > The dependencies are still broken. We could have: > > /------------------------------------------------\ > spam -- > > python-2.1 > \--------------------> python-eggs-2.1 ----------/ > > That makes spam dependent on the version of Python installed. Perhaps > I'm missing some detail of Donovan's plan.
The trick is the wrapper packages python-eggs version dependancy tied to the python wrapper package (look familiar?). The python-eggs package is used to pull in the latest python-eggs version package for the latest python, so it is tied to a particular version of the python wrapper package. /----------------------> python (2.1) --------\ spam -- / \ \ (>=2.1,<2.2) > python-2.1 \ / / \--> python-eggs /--> python-2.1-eggs ------/ when we upgrade to python 2.2 /---------------------> python (2.2)------------- python-2.2 spam -- \ (>=2.1,<2.2) \ / \--> python-eggs /---> python-eggs-2.1 -------- python-2.1 spam is broken because python-eggs is broken, but the dependancy system tells us it is broken because the python-eggs wrapper depends on a particular version of python that has been upgraded. The thing to remember is spam depends on the latest python and python-eggs. When python has been upgraded and python-eggs has not, the latest python + eggs combo is broken. There is nothing we can do about this... python (2.2) needs python-2.2-eggs for python + eggs to work. So we upgrade python-eggs; /----------------------> python (2.2)---------\ spam -- / \ \ (>=2.2,<2.3) > python-2.2 \ / / \--> python-eggs /---> python-2.2-eggs -----/ python-2.1-eggs ------- python-2.1 Now everything is working again. We have upgraded python and python-eggs, and created python-2.2 and python-2.2-eggs. Note that at no stage did python-2.1 and and python-2.1-eggs break, so any packages that depended directly on them (ie, tied to the particular 2.1 version packages) never broke. The latest version of python + eggs briefly broke as the packages were upgraded. This clearly shows the benefits and drawbacks of versioned vs unversioned dependancies. spam could have a versioned dependancy against python-2.1 and it would never break as python-2.2 was introduced (provided python-2.1 packages continued to exist), however, it would have to be upgraded every time python upgraded to use the latest python. By not depending on a particular version of python, it doesn't need to be upgraded to use the latest python, but requires that the latest python + eggs combo is not broken. In my above diagrams the (>=2.1,<2.2) dependancy could be replaced with a python-api-2.1 provided by python (as suggested by Neil), but I think this actually introduces confusion rather than convenience. The problem is that it doesn't really represent a particular version of the api, just a particular version range of the "latest" python package. Note that my proposal actually has a lot in common with Neil's. We are both using (>=2.1,<2.2) dependancies to ensure the latest python + modules breaks when not all of them are of the same version, though in his case he has introduced the confusing python-api as a shorthand for this. Perhaps using "python-base-2.1" or "python-latest-2.1" would be less confusing, but I still think the version range is clearer. The only real difference is I'm proposing the latest packages be small wrappers around python-2.1 versioned packages. This means old versioned packages get created as you go, rather than after python upgrades, and they don't break as python upgrades. It also allows other packages to choose whether they depend on python, or python-2.1, even when python 2.1 is the latest version. -- ABO: finger [EMAIL PROTECTED] for more information.