Re: Debian Python Policy [draft]

2001-10-02 Thread Neil Schemenauer
Carey Evans wrote:
 In my original example, spam embeds libpython2.1.so.  It would make
 sense for this to mean it depends on python-api-2.1, though this isn't
 what the current shlibs file says.

Only python can provide python-api-*.

  Neil




Re: Debian Python Policy [draft]

2001-10-02 Thread Jim Penny
On Tue, Oct 02, 2001 at 06:53:39AM -0700, Neil Schemenauer wrote:
 Carey Evans wrote:
  In my original example, spam embeds libpython2.1.so.  It would make
  sense for this to mean it depends on python-api-2.1, though this isn't
  what the current shlibs file says.
 
 Only python can provide python-api-*.
 

Why?  Could you better explain your reasoning here?  
On the face of it, it certainly seems that python-1.5 ought to be
able to provide python-api-1.5.

Jim Penny

   Neil
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 




Re: Debian Python Policy [draft]

2001-10-02 Thread Donovan Baarda
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.




Re: Debian Python Policy [draft]

2001-10-02 Thread Neil Schemenauer
Donovan Baarda wrote:
 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.

It does represent the version of the API (for bytecode and the extension
module binary interface).  I suppose I am abusing it in the sense that
only the python can provide it.  If we go with your plan we drop -api
bit and use python-X.Y instead.

  Neil