[Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals

Floris Bruynooghe floris.bruynooghe at gmail.com
Mon Oct 6 19:17:14 CEST 2008

On Sun, Oct 05, 2008 at 10:13:37AM -0600, zooko wrote:
> On Oct 1, 2008, at 19:10 PM, Tarek Ziadé wrote:
> For example: distribution A requires the functionality of ctypes.  That 
> part is statically, declaratively always true.
> However, distribution A doesn't necessarily require a *distribution*  
> named "ctypes".  If you are running on Python 2.6, then that  
> functionality is already present.  If there is a new distribution out  
> there named "new_ctypes" which provides the same functionality and the 
> same interface but is a completely different code base, then the  
> presence of "new_ctypes" satisfies distribution A's requirements.
> The former question is simple, static, and declarative.  The latter  
> question isn't.
> In most cases there is only one implementation of a given interface, so 
> we make do by equating the interface with the implementation.
> I wonder how Debian and Fedora handle this sort of issue?

I think Josselin mentioned this already for Debian's case, but
basically when python2.4 was default packages did say they wanted the
python-elementtree package.  So when python2.5 was packaged it said
"Provides: python-elementree" and all packages depending on
python-elementree will now be happy with just python2.5 installed.

It's slightly more complicated then that in reality, the full Provides
of python2.5 is:

Provides: python2.5-celementtree, python2.5-cjkcodecs, python2.5-ctypes,
 python2.5-elementtree, python2.5-plistlib, python2.5-wsgiref

The Debian infrastructure has various ways of helping packages cope
with the versioned package names in the above (and it was all still
very much a mess in python2.4 times).


Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

More information about the Distutils-SIG mailing list