1. As I told in the subject: conflict-version is undocumented (what's more,
documentation says you cannot use version numbers...). So we should fix
On Mon, Nov 19, 2007 at 01:16:10PM +0100, Nagy Gabor wrote: the 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).
Attaching a little patch.
Looks fine. Thanks.
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 alpm_vercmp). 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 patch) 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 ;-)
I found the current behavior a little confusing at first, but actually, it's alright. Suppose you have a package which depends on provision>=2.0-2 , and let's see what a package needs to provide for satisfying it : * 'provision' -> NO * 'provision 2.0' -> OK * 'provision 2.0-1' -> NO * 'provision 2.0-2' -> OK
So any 2.0-x dep will be satisfied by provision 2.0 .
Now, if the dependency is provision>=2.0 : * 'provision' -> NO * 'provision 2.0' -> OK * 'provision 2.0-1' -> OK * 'provision 2.0-2' -> OK
So the 2.0 dep will be satified by any 2.0-x
Well. Then choice b.) would be more plausible. But I can repeat myself: If a devel adds 'provision>=2.0-2' as depend, then this implicitly means that not "all" 'provision 2.0-x' version would satisfy this depend; and 'provision 2.0' says no info about -x... Personally I trusted on alpm_versioncmp [he decides if 2.0>=2.0-2 or not: currently it says yes, I say no], that's why I defined provversion as _valid_ package version. This provversion definition looks strict first. But if you think over this is not strict at all: You want to write "provision 2.0"; but I ask you to write "provision 2.0-1". What will happen? "provision 2.0-1" will satisfy 'provision>=2.0' but won't satisfy 'provision>=2.1' and so on. IMHO -x is rarely used in depends, so your -1 is doesn't count at all. If the package needs 'provision>=2.0-2' (because 'provision 2.0-1' is "buggy" <- rare case, because the source-code of 2.0-2 and 2.0-1 is the same), then we can easily decide whether your provision satisfies this or not. So we didn't lose anything, but we won can-decide-always. My reasoning above followed the the reasoning of a.) One may prefer b.), when provision defines a _set_ of "packages": so 'provision 2.0' means 'provision 2.0-ANY' <- this is how alpm_versioncmp works now. My main contra: In this case provision 'nvidia' would satisfy all 'nvidia ...' depend. So the devel simply cannot force pacman to upgrade the outdated dependency package which provides nvidia (which was installed from aur, -Su doesn't update it for example), but in fact this old nvidia provider is not sufficient for "nvidia>=123.456-7" depend. If the devel keeps this in mind, then he probably never uses versionless provision (now you can find versionless provisions only in the dbs), which is a big restriction. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/