[Rpm-maint] [RFC/PATCH] comparisons without release

seth vidal skvidal at fedoraproject.org
Tue Aug 10 15:57:02 UTC 2010


On Tue, 2010-08-10 at 11:17 -0400, James Antill wrote:
> On Mon, 2010-08-09 at 18:43 +0300, Anssi Hannula wrote:
> > Hi all!
> > 
> > Currently [1], if a package has
> > Provides: foo = 1.2
> > And another package has
> > Conflicts: foo < 1.2-1
> > 
> > The conflict does not trigger, as the releases will be ignored if one of the 
> > compared EVRs does not have it. (mdv bug #55810 [2])
> 
>  This can be easily fixed by doing:
> 
> Conflicts: foo <= 1.2-0
> 
> > Another similar case is:
> > A: Provides: foo = 1.2
> > B: Requires: foo = 1.2-2  (or >= 1.2-2)
> > The provides will match, which it IMHO should not be doing.
> 
>  Yeh, you are argue this is wrong ... but I could see how it could
> happen and be correct too.
>  The better semantics could be argued either way, when there is no
> release in the provides. The difference though is that current rpm and
> yum/smart/apt/zypper/etc. all use the current semantics, so arbitrarily
> changing it has a high incompatibility cost.
> 
>  One way to get what I think you want would be a patch to optionally
> reject a provides that doesn't have a release, at rpmbuild time. While I
> can't speak for Panu/etc. ... I don't see why that would be rejected,
> and you could then fix all your provides to have a release and
> everything would continue to work.
> 
> > One solution that may seem obvious at first is making the comparison ignore 
> > releases only if neither has one. However, it would break a situation where
> > A: Provides: foo = 1.2-5
> > B: Requires: foo = 1.2
> > 
> > So, in this "requires/conflicts/etc has RPMSENSE_EQUAL on non-released EVR"
> 
>  You can't change the semantics just for '=' operations, or you get
> insanity like:
> 
> Requires: foo = 1.2 (matches)
> Requires: foo >= 1.2 (doesn't match)
> 


A related and interesting question is this:

Why do obsoletes only work on pkg NAMES and conflicts work on pkg
provides?

from lib/depends.c

    /* Check provides against conflicts in installed packages. */
    while (rpmdsNext(provides) >= 0) {
        checkInstDeps(ts, dcache, p, RPMTAG_CONFLICTNAME,
rpmdsN(provides));
    }

    /* Check package name (not provides!) against installed obsoletes */
    checkInstDeps(ts, dcache, p, RPMTAG_OBSOLETENAME, rpmteN(p));
    }


Seems like the impact the same kind of thing.

I tried looking through the commits related to this for a justification
but I couldn't find one.

-sv




More information about the Rpm-maint mailing list