On Tue, Sep 30, 2008 at 3:17 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le mardi 30 septembre 2008 à 14:05 +0200, Tarek Ziadé a écrit :
>> On Tue, Sep 30, 2008 at 10:42 AM, Nicolas Chauvat
>> <[EMAIL PROTECTED]> 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.
>
The "Obsoletes" info could be used maybe. But the main problem I can
see is that
in any case several versions of the same module can be needed to build
one application.
That is what tools like zc.buildout or virtualenv exists : they are building
an isolated environment where they install the packages so a given
Python application
can run.
In other words the problem we have today with an OS-based installation is that
you cannot really have two versions of the same package installed,
that would make happy
two Python applications.
The setuptools project has partly improved this by providing a way to
install several
version of the same package in Python and give a way to select which
one is active.
>From your point of view, how could we solve it at Debian level ? to
kind of isolate a group
of packages that fit the needs of one given application ?
(btw A recent change it Python has allowed us to define per-user site-packages
http://mail.python.org/pipermail/python-dev/2008-January/076108.html)
>> 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.
>
Interesting.. That would mean you would do version conflict resolution
at the OS level, That makes me think about the previous point: how
two applications that use conflicting versions that are not comptabile
with each other (you have to choose one of them) can cohabit ?
Cheers
> 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.
>
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
