Requires(postun) doesn't seem to have an effect on ordering package removal

[Jeff Johnson]

tracker

[Caolan (caolan-redhat-bugs)]

Created attachment 328463
yum log

Description of problem:

Version-Release number of selected component (if applicable):
yum-3.2.20-8.fc11

How reproducible:
100%

Steps to Reproduce:
1. yum -y erase openoffice.org-fonts openoffice.org-ure
just to remove all openoffice.org components to clear the decks
2. yum -y install openoffice.org-pdfimport
3. yum -y -v erase openoffice.org-core openoffice.org-pdfimport

Actual results:
openoffice.org-core gets erased after openoffice.org-pdfimport does, so the use of unopkg in openoffice.org-pdfimport fails as it has already been deleted

Expected results:
That the Requires(postun): openoffice.org-core would cause openoffice.org-pdfimport to be removed before openoffice.org-core

[Caolan (caolan-redhat-bugs)]

Actual results:
openoffice.org-core gets erased *before* openoffice.org-pdfimport does, so the use of unopkg in openoffice.org-pdfimport fails as it has already been deleted

[seth (seth-redhat-bugs)]

reassigning since ordering is handled by rpm.

[Jeff (jeff-redhat-bugs)]

Yes, the version of RPM you are using does not have erasure ordering implemented,
and so
      Requires(postun): openoffice.org-core
which affects the erasure ordering context, doesn't apply. Period.

What _IS_ implemented in the RPM you are using, in lieu of proper
erasure ordering, is reversed install ordering, that's __ALMOST__
gud enuf. But the Requires(postun): context marker is ignored for
reversed install ordering.

[Caolan (caolan-redhat-bugs)]

Why was the "needinfo" from me flag set ? What info is needed ?

[seth (seth-redhat-bugs)]

Caolan,
 That was my fault. I was working on a bunch of bugs at the same time and I probably hit it mistakenly.
sorry.

[Jens (jens-redhat-bugs)]

And nor does Requires(preun) for me, or even Requires?? Maybe I am missing something but this looks kind of bad to me...

[Jens (jens-redhat-bugs)]

It seems a significant change of behaviour to me. I propose it should be a F11Blocker.

[Jeff (jeff-redhat-bugs)]

The lack of erasure ordering in rpm was _ALREADY_ a FC4 blocker. Certainly, make lack of
erasure ordering a F11 ordering as you wish. In fact, the erasure ordering development
in rpm was started the day that FC4 was released, and was largely finished 7 days later.

Two (or was it three, I fergit), years ago ...

[Bug (bug-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Jerry (jerry-redhat-bugs)]

Created attachment 347957
yum log

[Panu (panu-redhat-bugs)]

This isn't a regression, erasure ordering isn't really implemented in current released rpm versions. Current rpm.org HEAD has it though, whether it'll make it to F12 is another story as its linked to some API changes that make it unsuitable for pulling into 4.7.x as is.

[Panu (panu-redhat-bugs)]

*** Bug 478842 has been marked as a duplicate of this bug. ***

[Panu (panu-redhat-bugs)]

*** Bug 490975 has been marked as a duplicate of this bug. ***

[Caolan (caolan-redhat-bugs)]

*** Bug 532461 has been marked as a duplicate of this bug. ***

[Panu (panu-redhat-bugs)]

rpm 4.8.0-beta1 in rawhide (finally) has proper erasure ordering.

[David (david-redhat-bugs)]

*** Bug 583424 has been marked as a duplicate of this bug. ***