Red Hat Bugzilla – Bug 89740
RFE: Requires(preun,postun) erasure ordering
Last modified: 2007-04-18 12:53:20 EDT
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
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.
> 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
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
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
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
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
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 ***