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
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
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.
Thanks both for the answers,
"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/
Received on Mon Nov 16 04:29:31 2009