On Thu, 3 Feb 2005 10:41:21 -0500, Cress, Andrew R
<andrew.r.cress@xxxxxxxxx> wrote:
> rpm version used: rpm-4.2.1-4.2 (with RH EL3).
>
> I have an rpm package that works fine with rpm -e / rpm -i, but rpm -Uhv
> shows results in the following order, which seems illogical to me.
> %pre (new ver)
> %post (new ver)
> %preun (old ver)
> %postun (old ver)
>
> This obviously causes problems for me because the postun does some
> cleanup of files that the post-install conditionally set up. Can
> someone help me understand why rpm -Uhv isn't ordered like this:
> %preun (old ver)
> %postun (old ver)
> %pre (new ver)
> %post (new ver)
>
> Maybe there is a later version of rpm that handles this differently, but
> I would like to find a way to handle both rpm -i and rpm -U cleanly with
> rpm-4.2 and later.
>
Nope this has been this way from time immerial (call it RPM EPOCH) and
likely always will be this way. Mainly because, as someone has
astutely shown an example of with glibc, the system more rapidly
converges to a more stable state.
Note, rpm does all installs, and then all erases so it really looks like:
------ INSTALS ---
%pre (new ver pkg1)
%post (new ver pkg1)
...
%pre (new ver pkgN)
%post (new ver pkgN)
------- ERASURES ---
%preun (old ver pkg1)
%postun (old ver pkg1 )
...
%preun (old ver pkgN)
%postun (old ver pkgN)
What you need to do with your erase scriplets (and maybe your install
ones, don't know) is use the instance count that is passed in. RPM
passes as arg1 of every install scriptlet it runs the number of
instances of that packages header that will be in the database after
the package has been ran through the package state machine. That
pretty exact language, so here is what that boils down to:
INSTALL SCRIPTS
1 Pure install
2 Upgrade
3+ Its probably the kernel (-;
ERASE SCRIPTS
0 Pure erase
1 Upgrade
2+ Its probably the kernel.
Now in your erase scriptlets you only want to do something iif the
instance count
is zero, because that is when your package goes away completely. You
may want to do something in an upgrade cause, but that is not seen as
often.
Hope this helps...james
> Andy
>
> Andy Cress 803-216-2356 fax:803-216-2178
> Senior Software Engineer andrew.r.cress@xxxxxxxxx
> Intel Corporation, Columbia Design Center, CBA1
> 100 Center Point Cir., Suite 200, Columbia, SC 29210
> http://ipmiutil.sf.net http://scsirastools.sf.net
> BTW, I speak for myself, not for Intel Corp.
> "Do not merely look out for your own personal interests, but also for
> the interests of others." Phil 2:4
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/rpm-list
>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
