Neil Schemenauer <[EMAIL PROTECTED]> writes:
[...]
> Excellent point. I've updated the policy document to prevent this. The
> python package should provide python-api-X.Y. Module packages should
> depend on python-api-X.Y. If someone packages an older version of
> Python they should call it python-X.Y. Packaged modules for that Python
> should depend on python-X.Y. Older versions of Python should never
> provide python-api-X.Y.
I don't think this fixes all the possible problems. To start with,
here's a diagram of my initial set of installed packages, where an
arrow shows a dependency or provided-by.
/------------------------> python-2.1 -----\
spam -- > python
\---> python-eggs ---> python-api-2.1 ---/
Now Python 2.2 comes out, and apt upgrades python-eggs for some
reason. We then get:
/--------------------------------------------> python-2.1
spam --
\---> python-eggs' --> python-api-2.2 ---> python'
Yet again, spam runs the Python 2.1 interpreter, but depends on a
module in the 2.2 sys.path.
Does this mean that programs that depend on a particular version of
Python have to depend on python-api-2.2 as well?
My original suggestion would have lead to something like this:
spam --------------------------------------------------> python-2.1
\ / |
\--> python-2.1-eggs --> python-eggs ---/ v
python
When python-eggs is upgraded for Python 2.2, and doesn't provide
python-2.1-eggs any more, apt will refuse to upgrade it because spam's
dependencies would be broken.
I guess it might be worth having python-api-2.x anyway, to make sure
nothing gets upgraded until all packages are at the new version.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
