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.
