Bug 89740 - RFE: Requires(preun,postun) erasure ordering
RFE: Requires(preun,postun) erasure ordering
Status: CLOSED DUPLICATE of bug 89500
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks: 73970 FC5Blocker
  Show dependency treegraph
 
Reported: 2003-04-27 08:11 EDT by Ville Skyttä
Modified: 2007-04-18 12:53 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-06 10:56:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test specfile #1, the requiring one (413 bytes, text/plain)
2003-04-27 08:12 EDT, Ville Skyttä
no flags Details
Test specfile #2, the one required by foo (436 bytes, text/plain)
2003-04-27 08:13 EDT, Ville Skyttä
no flags Details

  None (edit)
Description Ville Skyttä 2003-04-27 08:11:55 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
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.
Comment 1 Ville Skyttä 2003-04-27 08:12:55 EDT
Created attachment 91317 [details]
Test specfile #1, the requiring one
Comment 2 Ville Skyttä 2003-04-27 08:13:30 EDT
Created attachment 91318 [details]
Test specfile #2, the one required by foo
Comment 3 Jeff Johnson 2003-04-29 11:44:47 EDT
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.
Comment 4 Ville Skyttä 2003-04-29 17:44:15 EDT
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?
Comment 5 Jeff Johnson 2003-04-30 09:32:37 EDT
Not implemented means exactly that.

Using shared files (i.e. identical file in 2 packages)
probably avoids the problem.
Comment 6 Enrico Scholz 2003-05-01 07:11:30 EDT
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.
Comment 7 Ville Skyttä 2003-05-01 09:24:24 EDT
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.
Comment 8 Jeff Johnson 2003-05-01 10:08:57 EDT
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).

Comment 9 James Olin Oden 2003-06-07 19:45:39 EDT
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.
Comment 10 Paul Nasrat 2005-04-27 11:10:46 EDT
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 
Comment 11 Tim Nelson 2005-07-24 19:45:21 EDT
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)
Comment 12 Ville Skyttä 2006-01-05 14:35:31 EST
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.
Comment 13 Ville Skyttä 2006-01-05 14:43:25 EST
Note also that this is not only an issue with Requires(preun/postun), but plain
Requires and PreReq too.
Comment 14 Jeff Johnson 2006-01-06 09:37:20 EST
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.
Comment 15 Gary Benson 2006-01-06 09:47:23 EST
The issue isn't that Requires(pre,post) doesn't work: it's that Requires(preun)
and Requires(postun) don't work.
Comment 16 Jeff Johnson 2006-01-06 10:54:01 EST
So this is Yet Another Request for erasure ordering, not otherwise, with additional
syntactical FUD that confuses the underlying issue.
Comment 17 Jeff Johnson 2006-01-06 10:56:09 EST

*** This bug has been marked as a duplicate of 89500 ***

Note You need to log in before you can comment on or make changes to this bug.