FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > RPM Package Manager

 
 
LinkBack Thread Tools
 
Old 04-10-2008, 02:11 AM
"Dave Peterson"
 
Default problem comparing capability version strings

Hi,

I have a question about capability version string comparisons.
Using RPM library calls, I examine the following Centos 5
packages:

package A: GConf2-devel-2.14.0-9.el5.i386.rpm
package B: GConf2-2.14.0-9.el5.i386.rpm

I see that one capability required by A is the following:

capability name: GConf2
capability version: 2.14.0
flags: RPMSENSE_EQUAL

I also see that one capability provided by B is the following:

capability name: GConf2
capability version: 2.14.0-9.el5
flags: RPMSENSE_EQUAL

To see if the GConf2 capability provided by B satisfies A's
requirement, I call rpmvercmp() as follows:

int result = rpmvercmp("2.14.0", "2.14.0-9.el5");

The return value is -1, indicating that "2.14.0-9.el5" is newer
than "2.14.0". Since the "flags" value for A is RPMSENSE_EQUAL,
and rpmvercmp() says that the version strings are not equal, I
conclude that the GConf2 capability provided by B does not
satisfy the GConf2 dependency required by A. Looking at the
packages installed on my own machine, I observe the following:

$ rpm -qa | grep GConf2
GConf2-2.14.0-9.el5
GConf2-devel-2.14.0-9.el5
$
$ rpm -q --provides GConf2-2.14.0-9.el5 | grep '^GConf2'
GConf2 = 2.14.0-9.el5
$
$ rpm -q --requires GConf2-devel-2.14.0-9.el5 | grep '^GConf2'
GConf2 = 2.14.0
$
$ rpm -q --whatprovides GConf2
GConf2-2.14.0-9.el5
$
$ rpm -V GConf2-devel-2.14.0-9.el5
$

It looks like B is the only installed package that provides the
GConf2 capability, and the RPM command doesn't complain that A is
missing any dependencies.

What is going on here? I suspect that the capability versions
"2.14.0" and "2.14.0-9.el5" should be considered equal due to
some usage convention(s) that I am unaware of. Is this correct?
What is the proper way to compare two capability version strings
in order to determine whether a package dependency is satisfied?
Is there one way that is guaranteed to work across all distros,
or does it vary from one distro to another?

Thanks,
Dave

_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
 
Old 04-10-2008, 10:40 AM
devzero2000
 
Default problem comparing capability version strings

This situation you describe is normal.

A package -dev generally requires only the NV capability of the primary package: it generally doesn't depends of the particolar Package Release eg. the rpm package lifecycle versus principal program lifecycle .


In this case Name=Gconf2 and Version is 2.14.0 (release is 0.el5). So the package A required dependency (on Version) is OK.

hth

On Thu, Apr 10, 2008 at 4:11 AM, Dave Peterson <dave_peterson@bigfix.com> wrote:

Hi,



I have a question about capability version string comparisons.

Using RPM library calls, I examine the following Centos 5

packages:



* *package A: GConf2-devel-2.14.0-9.el5.i386.rpm

* *package B: GConf2-2.14.0-9.el5.i386.rpm



I see that one capability required by A is the following:



* *capability name: * *GConf2

* *capability version: 2.14.0

* *flags: * * * * * * *RPMSENSE_EQUAL



I also see that one capability provided by B is the following:



* *capability name: * *GConf2

* *capability version: 2.14.0-9.el5

* *flags: * * * * * * *RPMSENSE_EQUAL



To see if the GConf2 capability provided by B satisfies A's

requirement, I call rpmvercmp() as follows:



* int result = rpmvercmp("2.14.0", "2.14.0-9.el5");



The return value is -1, indicating that "2.14.0-9.el5" is newer

than "2.14.0". *Since the "flags" value for A is RPMSENSE_EQUAL,

and rpmvercmp() says that the version strings are not equal, I

conclude that the GConf2 capability provided by B does not

satisfy the GConf2 dependency required by A. *Looking at the

packages installed on my own machine, I observe the following:



* *$ rpm -qa | grep GConf2

* *GConf2-2.14.0-9.el5

* *GConf2-devel-2.14.0-9.el5

* *$

* *$ rpm -q --provides GConf2-2.14.0-9.el5 | grep '^GConf2'

* *GConf2 = 2.14.0-9.el5

* *$

* *$ rpm -q --requires GConf2-devel-2.14.0-9.el5 | grep '^GConf2'

* *GConf2 = 2.14.0

* *$

* *$ rpm -q --whatprovides GConf2

* *GConf2-2.14.0-9.el5

* *$

* *$ rpm -V GConf2-devel-2.14.0-9.el5

* *$



It looks like B is the only installed package that provides the

GConf2 capability, and the RPM command doesn't complain that A is

missing any dependencies.



What is going on here? *I suspect that the capability versions

"2.14.0" and "2.14.0-9.el5" should be considered equal due to

some usage convention(s) that I am unaware of. *Is this correct?

What is the proper way to compare two capability version strings

in order to determine whether a package dependency is satisfied?

Is there one way that is guaranteed to work across all distros,

or does it vary from one distro to another?



Thanks,

Dave



_______________________________________________

Rpm-list mailing list

Rpm-list@redhat.com

https://www.redhat.com/mailman/listinfo/rpm-list



_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
 
Old 04-19-2008, 07:30 PM
"Jeff Johnson"
 
Default problem comparing capability version strings

On Wed, Apr 9, 2008 at 10:11 PM, Dave Peterson <dave_peterson@bigfix.com> wrote:



To see if the GConf2 capability provided by B satisfies A's

requirement, I call rpmvercmp() as follows:



* int result = rpmvercmp("2.14.0", "2.14.0-9.el5");

The problem is likely conceptual.


rpmvercmp compares strings according to rpm's comparison rules.

However rpm uses the triple {Epoch,Version,Release} to determine newer.

That means that rpmvercmp is called multiple times (Epoch is always a digit string,

strcmp on zero-padded strings is used for infinite precision, but the comparison
rules for digit-only strings do not need to use rpmvercmp). rpmvervmp is definitely
called for each of Version and Release.

Your example is comparing a Version "2.14.0" with a Version-Release "2.14.0-9.el5".


That needs to be done by splitting on the '-' in "2.14.0-9.el5" and calling rpmvercmp
twice.

You are still likely to be surprised by the results.

rpmvercmp basically tries to compare alphas with alphas, and digits with digits,

because originally (before YYYYMMDDhhmmss digit strings were noticed to
exceed 32 bits) compared by converting to ints.

That's the sensible part.

The scwewy part(s) of rpmvercmp include the following:

***1) leading 0's are ignored. e.g. 5.000000000003 is greater than 5.2 because 3 > 2
***2) all punctuation is ignored and treated as equivalent. so 5.2 and 5_2 are equal.
and (finally, this is the one that you will be surprised at)

**3) mixed mode (as in digit string compared to something other than digit string) is reversed
**from the comparison order one would expect. But its very hard to expect a result from
** a comparison between something and nothing, consider what happens to strcmp** if fed NULL or "", two forms of expressing nothing.


All well known flaws, been there forever, nothing can be done without coordinating the
change, which is bloody unlikely to happen.

hth

73 de Jeff
*
_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
 
Old 04-24-2008, 12:08 AM
"Dave Peterson"
 
Default problem comparing capability version strings

Ok, thanks for the info!* I recently discovered
that I can use rpmdsSingle()
to manufacture an rpmds object, and then compare rpmds
objects using
rpmdsCompare().* My code looks roughly like this
(with some error checking
omitted to keep it short):
*
struct DepInfo
*{ rpmTag tag;
** const char* n;* //
name
** const char* evr;* // epoch version
release
** int_32 flags;
*};
*
int compare(struct DepInfo* d1, struct DepInfo*
d2)
*{ rpmds ds1, ds2;
** int result;
*
** ds1 = rpmdsSingle(d1->tag, d1->n,
d1->evr, d1->flags);
** ds2 = rpmdsSingle(d2->tag, d2->n,
d2->evr, d2->flags);
** ds1 = rpmdsInit(ds1);
rpmdsNext(ds1);
** ds2 = rpmdsInit(ds2);
rpmdsNext(ds2);
** result = rpmdsCompare(ds1,
ds2);
** rpmdsFree(ds1);
rpmdsFree(ds2);
** return result;
*}
*
This type of approach seems to work for me.* I
guess rpmdsCompare()
is probably calling rpmvercmp() internally to compare
pieces of the
capability version strings.
*
Dave
*
> The problem is likely conceptual.
>
>
rpmvercmp compares strings according to rpm's comparison rules.
>
>
However rpm uses the triple {Epoch,Version,Release} to determine
newer.
>
> That means that rpmvercmp is called
multiple times (Epoch is always a digit string,
> strcmp on zero-padded strings is used for
infinite precision, but the comparison
>
rules for digit-only strings do not need to use rpmvercmp). rpmvervmp is
definitely
> called for each of
Version and Release.
>
> Your example is comparing a Version
"2.14.0" with a Version-Release "2.14.0-9.el5".
>
>
That needs to be done by splitting on the '-' in "2.14.0-9.el5" and
calling rpmvercmp
> twice.
>
>
You are still likely to be surprised by the results.
>*
>
rpmvercmp basically tries to compare alphas with alphas, and digits with
digits,
> because originally (before
YYYYMMDDhhmmss digit strings were noticed to
> exceed 32 bits) compared by converting to
ints.
>
> That's the sensible part.
>
>
The scwewy part(s) of rpmvercmp include the following:
> ***1) leading 0's are
ignored. e.g. 5.000000000003 is greater than 5.2 because 3 > 2
> ***2) all punctuation is
ignored and treated as equivalent. so 5.2 and 5_2 are equal.
> and (finally, this is the one that you will
be surprised at)
> **3)
mixed mode (as in digit string compared to something other than digit string) is
reversed
> **from the
comparison order one would expect. But its very hard to expect a result
from
> ** a comparison between something
and nothing, consider what happens to strcmp
> ** if fed NULL or "", two forms
of expressing nothing.
>
> All well known flaws, been there forever,
nothing can be done without coordinating the
> change, which is bloody unlikely to
happen.
>
> hth
>
>
73 de Jeff

_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
 

Thread Tools




All times are GMT. The time now is 03:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org