Andi Payn <[EMAIL PROTECTED]> writes:
> On Monday 21 July 2003 19:43, you wrote:
> > Le Lundi 21 Juillet 2003 17:44, Andi Payn a �crit :
> > > Under rpm 4.0, installing or upgrading a package only checked its
> > > obsoletes against the main package name. Now, 4.2 also checks against any
> > > virtual names provided by the package. So, with 4.0, two packages that
> > > provided and obsoleted the same virtual name wouldn't interfere; now they
> > > do.
> >
> > After checking, I am not sure:
>
> I've attached the simplest possible packages to demonstrate the problem.
>
> 1. rpmbuild -ba dummy1, dummy2-1mdk, and dummy2-2mdk.
> 2. rpm -Uvh dummy1-1.0-1mdk.noarch.rpm
> now dummy1 is installed
> 3. rpm -Uvh dummy2-1.0-1mdk.noarch.rpm
> now dummy1 and dummy2 are both installed
> 4. rpm -Uvh dummy2-1.0-2mdk.noarch.rpm
> now dummy1 is gone; onldummy2 is installed
Simpler case, do step 1, 2, 4 without 3.
Version of obsoletes are not used, but version of packages are used directly,
this is the behaviour of the fixes taken from rpm-4.2.1.
> Apparently this is only triggered when upgrading an existing package to a
> later version (step 4). That's what your test was missing.
>
> The obsoletes tag in dummy1 and the provides in dummy2 are unnecessary to
> trigger the problem, but I put them in to better simulate the situation that
> seems to turn up in real packages.
>
> If you remove the "Provides" tag from dummy1, the problem goes away. If you
> remove the "Obsoletes" tag from dummy2, the problem goes away. If you version
> the "Obsoletes" tag so it doesn't match dummy1, the problem goes away.
I may simply remove Obsoletes management on virtual provides as it seems really
strange and since RH added colored tag on package to allow the obsoletes to
work, and these tags are computed from a binary OR with the colors of file (it
seems so ?).
In fact, these errors are triggered because we provides and obsoletes the same
things in a package, so we may have a different point of view of RH has on the
obsoletes in fact.
The fix taken from rpm-4.2.1 which seems to fix the problem of kernel upgrade
removing other kernel is wrong, we have to change our point of view of obsoletes
behaviour or drop this behaviour of obsoletes in rpm, but we may lose
compability with RH, unless of course this is a bug in rpm.
The problem is the semantics we affect, a package provides a property and
another obsoletes it, does we need to keep it or ignore it ?
I propose this patchs, which is a bit aggressive but solves the problem (we are
losing compability with rpm of RH maybe we lose bug too ?).
273,313d272
< obsoletes = rpmdsLink(rpmteDS(p, RPMTAG_OBSOLETENAME), "Obsoletes");
< obsoletes = rpmdsInit(obsoletes);
< if (obsoletes != NULL)
< while (rpmdsNext(obsoletes) >= 0) {
< const char * Name;
<
< if ((Name = rpmdsN(obsoletes)) == NULL)
< continue; /* XXX can't happen */
<
< /* Ignore colored obsoletes not in our rainbow. */
< dscolor = rpmdsColor(obsoletes);
< if (tscolor && dscolor && !(tscolor & dscolor))
< continue;
<
< /* XXX avoid self-obsoleting packages. */
< if (!strcmp(rpmteN(p), Name))
< continue;
<
< mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, Name, 0);
<
< xx = rpmdbPruneIterator(mi,
< ts->removedPackages, ts->numRemovedPackages, 1);
<
< while((oh = rpmdbNextIterator(mi)) != NULL) {
< /* Ignore colored packages not in our rainbow. */
< ohcolor = hGetColor(oh);
< if (tscolor && hcolor && ohcolor && !(hcolor & ohcolor))
< /[EMAIL PROTECTED]@*/ continue;
<
< /*
< * Rpm prior to 3.0.3 does not have versioned obsoletes.
< * If no obsoletes version info is available, match all names.
< */
< if (rpmdsEVR(obsoletes) == NULL
< || rpmdsAnyMatchesDep(oh, obsoletes, _rpmds_nopromote))
< xx = removePackage(ts, oh, rpmdbGetIteratorOffset(mi), pkgKey);
< }
< mi = rpmdbFreeIterator(mi);
< }
< obsoletes = rpmdsFree(obsoletes);
<
Fran�ois.
