[Distutils] [pyconuk] "just use debian"

Nicolas Chauvat nicolas.chauvat at logilab.fr
Tue Sep 30 10:42:53 CEST 2008


Hi,

On Mon, Sep 29, 2008 at 02:09:15PM +0200, Tarek Ziadé wrote:
> That is exactly what was brought in the other thread in distutils-SIG,
> providing the package metadata in a simple way for os-vendors, without
> having to deal with things like setup.py
> 
> Then having third party applications that knows how to use them
> to install things in debian, or whatever the system is.
> 
> Now, the question is,  what would debian miss in here to install:
> 
> http://www.python.org/dev/peps/pep-0345/
> 
> If you can come up with a list of missing elements, we could
> probably start to work on a PEP together.

I started a thread on debian-python to ask for help:
http://lists.debian.org/debian-python/2008/09/msg00025.html

Here the answer from Josselin Mouette who is the author of
python-support, a tool that dramatically eases the packaging of Python
code for Debian.

---------------------------------------------------------------------
Le lundi 29 septembre 2008 à 15:12 +0200, Nicolas Chauvat a écrit :
> Here is where we stand today:
>http://mail.python.org/pipermail/distutils-sig/2008-September/010126.html

This looks like a step in the right direction if we want to generate
inter-module dependencies.

Most things defined in the PEP will not be useful for packaging,
except for making something like a dh_make_python almost trivial to
write. The one thing that we'd almost certainly use is the Requires
and Provides fields.

However you should be careful with the notion of version. It is nice
to have a lot of flexibility in specifying versioned dependencies, but
the more stuff the norm allows, the more complicated it will be to
translate this into inter-package dependencies.

For example, if you require a minimal version of 1.4, you can
translate this to a package version of 1.4; it is a bit hackish but
will work if you handle epochs correctly. But if the package you
depend on has a Provides: blah (1.4), you have no way to map that to a
dependency, because you can't know what other versions of the package
will provide.

In all cases, it will be necessary to manually add shlibs-like
information to the packages; they could be partly autogenerated like
symbol files, but you need a mapping between provided modules and the
first version of the package that provides it.
---------------------------------------------------------------------

Good to see this is moving forward :)

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


More information about the Distutils-SIG mailing list