[pacman-dev] conflict and provision versions

[Nagy Gabor]

> On Mon, Nov 19, 2007 at 01:16:10PM +0100, Nagy Gabor wrote:
> > 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).
> > 
> 
> 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/