[pacman-dev] conflict and provision versions
ngaba at bibl.u-szeged.hu
Mon Nov 19 07:16:10 EST 2007
> On Sat, Nov 17, 2007 at 05:55:44PM +0100, Nagy Gabor wrote:
> > I'm writing from an internet caffee, because the results I found shocked
> > The blames (just joking):
> > 1. "... 'cron 2.0' to satisfy the 'cron>=2.0' dependency of other
> > Only valid version numbers are allowed, for example 2.0-1.
> I actually hesitated when writing this. And I'm still confused.
> Is it ok to have a 'cron>=2.0' dependency, but not providing 'cron 2.0' ?
> Most versioned dependencies don't include any revisions.
> See grep -r 'depends.*>=' /var/abs/core
1. As I told in the subject: conflict-version is undocumented (what's more, the
documentation says you cannot use version numbers...). So we should fix this:
a.) conflict syntax is the same as depends syntax
b.) 'foo' conflict covers exactly the same set of packages as 'foo' depends (so
for example (versioned ;-) provisions are also checked).
2. Back to versioned provisions:
My concept of versioned provision was: alternative (pkgname, pkgver) pairs
[which means this package is equivalent with _one_ certain package], where
pkgver="" is also allowed [which means in my concept that pkgver was "lost", NOT
any; this decision is crutial here, one of the must important changes(*)]<- this
is the clearest and easiest-to-implement solution imho (you needn't modify
So for example kernelck-2.6.22-1 provides kernel-2.6.22-1 and so on.
Vmiklos suggested on irc, that I should use depends-like syntax; such as
provides 'foo>=1.0' but I didn't like that because this can lead to decision
problems. What do you think? If you also prefer this (Xavier, you mentioned
dependencies here, too), then my compromise: change the 'provname provver'
syntax to 'provname=provver' (this is just a s/' '/'='/ in my patch), and later
you can implement more general provides syntax without breaking the current "style".
(*)So I ask you again (you should make a decision):
What should versionless provision mean?
a.) this provision does NOT satisfy 'provision>=2.0-1' (I've chosen this in my
b.) 'no provver' means 'ANY provver' (this is also acceptable, but imho
'provision>=2.0-1' means that we cannot accept "any" provision, just the "new" ones)
c.) current method: use pkgver (imho forget it ;-)
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/
More information about the pacman-dev