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