Conflicts vs Obsoletes

[Marc MERLIN]

This is against an old rpm (4.0.2) but I think this behaviour hasn't changed
in a while.

If I have a directory with bash.rpm
and someone builds newbash.rpm with Obsoletes: bash.rpm
things works as expected:
rpm -U newbash.rpm
removes bash.rpm

Now, unless something very wonoky happened, I think I think I saw
rpm -U bash.rpm succeeding (the files don't conflict).

Is that possible/normal?

In that case, I put both Conflicts: bash.rpm / Obsoletes: bash.rpm
in newbash.rpm?

But if I do that, rpm -U newbash.rpm should still work, however, if someone
tries rpm -U bash.rpm, should it just be a no-op that won't cause an error,
or would it try to install bash and then fail due to the conflict?

Yes, I can build dummy packages to try all this, but at the same time I want
to make sure I understand expected (not observed) behaviour as well as well
as what is recommended in case like this.

Thanks,
Marc

[Eric MSP Veith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Marc MERLIN
This is against an old rpm (4.0.2) but I think this behaviour hasn't
changed in a while.
If I have a directory with bash.rpm
and someone builds newbash.rpm with Obsoletes: bash.rpm
rpm -U newbash.rpm
removes bash.rpm
Now, unless something very wonoky happened, I think I think I saw
rpm -U bash.rpm succeeding (the files don't conflict).
Is that possible/normal?

Yes. The pourpose of the "Obsoletes" tag is to mark an obsoletion if the
package name differs. For example, if you habe bash-2.05-1.i386.rpm and
bash-3.0-1.i386.rpm, the latter will cause and upgrade as it is newer than
bash-2.05 -- quite naturally. However, consider the case where you are
forced to change the package names for whatever reason. For example, the
"foo" project begins to develop the "foo2" package in parallel to the old
"foo", and you want to packge both. "foo2" will of couse supersede "foo",
but RPM cannot guess. So you put an "Obsoletes: foo" into your "foo2.spec",
and the upgrade will work.

As for conflicts, it does what it's named after: It marks a conflict.
"Conflicts" will cause the install/upgrade to fail and therefore forbids an
installation/upgrade. In contrast, "Obsoletes" forces an upgrade.

Post by Marc MERLIN
In that case, I put both Conflicts: bash.rpm / Obsoletes: bash.rpm
in newbash.rpm?

Depdends on what you express. Normally, "Obsoletes" suffices.

Post by Marc MERLIN
But if I do that, rpm -U newbash.rpm should still work, however, if
someone tries rpm -U bash.rpm, should it just be a no-op that won't
cause an error, or would it try to install bash and then fail due to the
conflict?

If you put "Obsoletes: bash" into "newbash.rpm", it will cause an "rpm -Uvh
bash.rpm" to fail with the message that a newer version is already
installed.

As a real-life example, I commonly use "Obsoletes" when I find that some
library package's soversion is becoming important. I have a package called
"libvuurmuur". When I found that packages linked against libvuurmuur.so.0
explicitly and some others needed a newer version of libvuurmuur, I decided
to change the package's name to "libvuurmuur0". To not cause confusion, I
put an "Obsoletes: libvuurmuur < %{version}-%{release}" into the specfile,
thereby causing the old "libvuurmuur" to be removed and smoothly replaced by
"libvuurmuur0". If I get to install "libvuurmuur1" some day, I won't have
and problems.

In contrast, I had for some time both KDE 3 and KDE 4 packages but didn't
want users to installed both "kdegraphics" version 3 AND 4, so I put a
"Conflicts: kdegraphics < 4.0" into the specfile for kdegraphics-4. It made
more sense because I couldn't just force an upgrade.

HTH.

-- Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksApk8ACgkQhS0drJ3goJKz5QCfZ/2XnCNWMU6y0GL6en9LFine
GWEAniqLR2iQC02JRn6yR9e8AAdXZIh+
=5xZu
-----END PGP SIGNATURE-----
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users-***@public.gmane.org

[Jeff Johnson]

Post by Eric MSP Veith

Post by Marc MERLIN
In that case, I put both Conflicts: bash.rpm / Obsoletes: bash.rpm
in newbash.rpm?

Depdends on what you express. Normally, "Obsoletes" suffices.

The fundamental design flaw with Obsoletes: is lack of persistence.

So if you undertake a old -> new renaming, and the "new" package has
Obsoletes: old
then the "old" package is erased.

But nothing stops re-installing the "old" package.

Which is often why a Conflicts: is being added with Obsoletes:, for
persistence.

I'm likely to make Obsoletes: persistent Real Soon Now. But that
won't change widely deployed RPM behavior.

73 de Jeff

[Eric MSP Veith]

Post by Jeff Johnson
So if you undertake a old -> new renaming, and the "new" package has
Obsoletes: old
then the "old" package is erased.
But nothing stops re-installing the "old" package.
Which is often why a Conflicts: is being added with Obsoletes:, for
persistence.

Jikes! Thanks for pointing that mistake of mine out, Jeff.

-- Eric

[Marc MERLIN]

Post by Eric MSP Veith
As for conflicts, it does what it's named after: It marks a conflict.
"Conflicts" will cause the install/upgrade to fail and therefore forbids an
installation/upgrade. In contrast, "Obsoletes" forces an upgrade.

Right. I just initially figured that if B obsoletes and replaces A, you
shouldn't just be able to reinstall A when B is there.

Post by Eric MSP Veith

Post by Marc MERLIN
But if I do that, rpm -U newbash.rpm should still work, however, if
someone tries rpm -U bash.rpm, should it just be a no-op that won't
cause an error, or would it try to install bash and then fail due to the
conflict?

If you put "Obsoletes: bash" into "newbash.rpm", it will cause an "rpm -Uvh
bash.rpm" to fail with the message that a newer version is already
installed.

didn't seem to for me.

Post by Eric MSP Veith
The fundamental design flaw with Obsoletes: is lack of persistence.
So if you undertake a old -> new renaming, and the "new" package has
Obsoletes: old
then the "old" package is erased.
But nothing stops re-installing the "old" package.

Ok, so that's what I saw.

Post by Eric MSP Veith
Which is often why a Conflicts: is being added with Obsoletes:, for
persistence.

and what we had to do. Just making sure it was supposed to be that way since
it wasn't quite what I thought was expected :)

Post by Eric MSP Veith
I'm likely to make Obsoletes: persistent Real Soon Now. But that
won't change widely deployed RPM behavior.

Right :)

Thanks both for the answers,
Marc

[Jeff Johnson]

Post by Marc MERLIN
Yes, I can build dummy packages to try all this, but at the same time I want
to make sure I understand expected (not observed) behaviour as well as well
as what is recommended in case like this.

You likely want to build packages and test for careful work.

There's actually a Conflicts: bug that goes way way way back to
rpm-3.0.2
with missing values that was reported about a month ago.

These 2 values in different packages should Conflict: and don't:

Conflicts: suspend-scripts < 1.27-2mdv2007.1

and

Provides: suspend-scripts = 1.27

The issue is with the missing value for Release: in the Provides:
and the comparison behavior isn't correct for Conlficts:.

Your examples did not supply {Epoch,Version,Release} at all, and so
may well
have odd/unexpected behavior.

I can point you at the line that needs to be changed if you want to fix
the issue. The code looks something like this:

if (sense == 0) {
sense = rpmvercmp(aV, bV);
if (sense == 0 && aR && *aR && bR && *bR)
sense = rpmvercmp(aR, bR);
}

and the "... aR && *aR && bR && *bR" is what is b0rken. The fix
is to default missing values to "" and actually call rpmvercmp()
with "" values.

I can send a patch for rpm-4.0.2 if interested. Just too lazy to look
atm ...

hth

73 de Jeff