Le mardi 30 septembre 2008 à 14:05 +0200, Tarek Ziadé a écrit :
On Tue, Sep 30, 2008 at 10:42 AM, Nicolas Chauvat <nicolas.chauvat@logilab.fr> wrote:
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.
I am not sure to fully understand, could you provide a real-word example ?
Let’s say you have module bar, contained in the package python-bar. The last version is 1.4. After that version, it is decided to distribute it in the same tarball as module bar. It is therefore moved to the package python-foo, which is at version 1.2. In this case, you can specify in the metadata : Provides: foo Provides: bar (1.4) This is the typical use case for versioned provides. Let’s say application baz requires module bar with minimal version 1.3, it will have as dependency: Requires: bar >= 1.3 This way it will be happy to find the versioned provides if module foo is installed, and everyone is happy. Well, except that, if you try to build a package of baz, there is no way to express correctly that you depend on python-bar (>= 1.3) or python-foo (>= 1.2). This is why I’d prefer to have versioned provides simply not part of the specification. Another thing that can cause issues is exact dependencies. If you require strictly version 1.1 of foo, there is no good way of translating it into a package dependency. All the following will have serious drawbacks when facing the real world: python-foo (>= 1.1), python-foo (<< 1.1.~) python-foo (>= 1.1), python-foo (<< 1.2) python-foo (= 1.1-1) If you allow to specify requires and provides in a sophisticated way, people will use it and we will run into unmanageable situations when converting them to packages. If a module provides an API at version 1.2, it will have to still provide it at version 1.3, otherwise the module should remain private and never be installed in a public python module directory. Just like we rename C libraries when their ABI changes, we need to reach a situation where we can make the same assumptions about python modules.
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.
Is this related ? http://lists.debian.org/debian-dpkg/2006/01/msg00118.html
Yes. The thread you point to did not let to something being actually implemented, because at that moment, we lacked the necessary metadata. Since then, setuptools appeared, but it does not provide it in a sane way and it is not universal. Which is why I’m interested into the metadata format that’s discussed here. From this metadata, we will be able to generate some files that express what is provided and the required version. Something like: foo 1.0-1 bar 1.2~beta3 This way, if another package requires foo (> 1.1) and bar (without a version requirement), we can convert this dependency into: python-foo (>= 1.1), python-foo (>= 1.2~beta3) which can then be factorized, of course. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.