Requires(preun) and Requires(postun) don't work as expected, ie. the order is not taken into account. Requires(pre) and Requires(post) on the other hand work fine. By specifying "Requires(preun): bar" in a "foo" package, I'd expect that rpm would make sure that "bar" doesn't get uninstalled before "foo" is (or to me more exact, before the %preun scriptlet of "foo" is run). Ditto for %postun. Experimentation using rpm-4.2 shows that this is not the case, rpm seems to completely ignore the ordering. I'll attach a couple of specfiles I used to test this with. foo.spec contains the Requires(...): bar. When both packages are installed and the preun stuff in foo.spec is uncommented, "rpm -e bar foo" works, but "rpm -e foo bar" doesn't. Ditto for postun in foo.spec.
Created attachment 91317 [details] Test specfile #1, the requiring one
Created attachment 91318 [details] Test specfile #2, the one required by foo
Yup, rpm does not do erasure ordering. The preun/postun context marker is still important, as they identify dependencies that are unimportant while installing, but must be satisifed in order to erase successfully. There's an RFE for erasure ordering already against rpm, implementation deferred until needed.
Ok, thanks for the confirmation. However, nowadays if packagers care about the proper erasure ordering, what is The Way to achieve it? Can the (semantically not quite correct) Requires(pre) and Requires(post) be used, or the legacy PreReq?
Not implemented means exactly that. Using shared files (i.e. identical file in 2 packages) probably avoids the problem.
comment 3: > implementation deferred until needed. It is needed ;) Currently, when creating addon-packages which are using directory-structures of a base-project (e.g. 'xmms-foobar' creates files in /usr/lib/xmms/Input which is owned by 'xmms'), the addon-packages have always to own the complete directory- structure (e.g. with %dir /usr/lib/xmms, ...; %dir /usr is theoretically needed also, but I would avoid it). On removal, the packages can be reordered so that the base-package (xmms) will be removed before the addon (xmms-foobar). Without the %dir-ownerships, some parts of the directory-structure of the base-package can remain. http://www.tu-chemnitz.de/~ensc/A.spec demonstrates this; read the comments at the top.
Yep, I'd appreciate if this would be implemented too. To comment 5: what do you mean by including identical files in 2 packages, doesn't that create a conflict? update-alternatives? Maybe I'm being blind but I don't see how this could cleanly be used to work around the erasure ordering problem.
Look, even if I had an implementation to do erasure ordering *today*, you're nuts to try to package depending on erasure ordering, because you package will break again and again and again with legacy versions of rpm. No conflicts if files are identical, easily achieved with sub-packages. And rpm has always behaved this way, so there are no legacy issues. So try putting your helper script in both packages that need. And if that doesn't work, the next answer is to put identical copies with different names in two packages (or otherwise rearrange your packaging).
Jeff, just so you know this can be a serious problem with administrative packages in a rollback. As a specific case, at Tekelec we use a wrapper for RCS to check our config file changes into a local source repository. In a rollback, we have each package rollback to the revision that was on the box at the time it made its changes. This algorithm is of course broken, because rpm does not maintain order on erasures. Course, there is the need to be able to tell that you are in a rollback also. Anyway the quick fix for us is to have the wrapper centrally manage config file rollbacks...not done yet but that seems simpler than get rpm to sort erasures...sigh.
This should work in rpm-4.4.1-11 in rawhide tomorrow. Obviously as jbj comments that legacy rpm does not support this but Fedora Core 4 and later will. I'd anticipate some time before this support is everywhere
Is this going to be backported to RHEL 3? Is that what you meant by anticipating that it will be supported everywhere? (RHEL3 is rpm-4.2.3-21_nonptl)
This is still an issue as of rpm-4.4.2-11 (post-FC5test1 Rawhide) using the specfiles from comments 1 and 2, setting FC5Blocker per Jeremy's request.
Note also that this is not only an issue with Requires(preun/postun), but plain Requires and PreReq too.
Using syntax that is known broken in released versions of rpm in current spec files is just plain stupid, an accident that will happen again and again and again. One can *ALWAYS* do Requires(pre): yadda Requires(post): yadda WONTFIX in the sense that releasing rpm everywhere is just not going to happen, the syntax "works" in FC released rpm and later.
The issue isn't that Requires(pre,post) doesn't work: it's that Requires(preun) and Requires(postun) don't work.
So this is Yet Another Request for erasure ordering, not otherwise, with additional syntactical FUD that confuses the underlying issue.
*** This bug has been marked as a duplicate of 89500 ***