Conflicts vs Obsoletes
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 -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: API Functions that Install, Erase and View packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What programing language? :-) On Thursday 12 November 2009, Manoj Palhade mpalh...@googlemail.com wrote: Dear Eric, Sorry for late reply. You are correct; I am looking for programmatic way of installing/remove/query RPM Packages. Can you please elaborate more on this “TransactionSet” and “RPM's workhouse”. I am bit new to this terminology. Do you have sample program to do above mentioned task Thanks and Regards, Manoj Palhade On Tue, Nov 3, 2009 at 6:49 AM, Eric MSP Veith eve...@wwweb- library.netwrote: I guess he wants to programmatically install/remove packages. If running rpm from your own project isn't an option, start with reading about the TransactionSet and what you can get from it. It's RPM's workhouse, and nearly everything start with it. -- Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksAo4cACgkQhS0drJ3goJI10QCfdaa1C7gbkJKgycOKdCVKurJV QSoAn0x2//nWMZI987gkgtmbhVFfvkBR =+ZRH -END PGP SIGNATURE- __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Conflicts vs Obsoletes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 16 November 2009, Marc MERLIN marc_...@merlins.org wrote:
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?
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.
In that case, I put both Conflicts: bash.rpm / Obsoletes: bash.rpm
in newbash.rpm?
Depdends on what you express. Normally, Obsoletes suffices.
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 Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: Conflicts vs Obsoletes
On Nov 15, 2009, at 7:31 PM, Marc MERLIN wrote:
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
smime.p7s
Description: S/MIME cryptographic signature
Re: Conflicts vs Obsoletes
On Nov 15, 2009, at 8:09 PM, Eric MSP Veith wrote: 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 smime.p7s Description: S/MIME cryptographic signature
Re: Conflicts vs Obsoletes
On Mon, Nov 16, 2009 at 02:09:35AM +0100, Eric MSP Veith wrote: 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. 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. On Sun, Nov 15, 2009 at 09:11:57PM -0500, Jeff Johnson wrote: 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. 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 :) 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 -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
