Upgrading breaks files

devzero2000 pinto.elia at gmail.com
Mon Oct 24 16:08:41 UTC 2011

On Mon, Oct 24, 2011 at 5:18 PM, Marco <listaddr at gmail.com> wrote:

> Hello,
> for reasons I won't go into here, I have a package that installs a
> file under /etc/package/file.instancename, then the postinst script
> appends the contents of that file to another (pre-existing) file on
> the filesystem (say, /etc/mainfile). Similarly, the preun script
> removes that block of data from the main file and leaves it as it was
> before the installation. This works nicely and allows us to install
> multiple instances of the package, each one contributing its own
> fragment to the main file, and without interfering with each other.
> The postinst script is carefully designed to do the right thing and
> not add the fragment twice (essentially, it either deletes the
> existing fragment in /etc/mainfile and readds the package-provided
> one, or doesn't touch it, depending on configuration parameters; but
> it does work ok).
> This breaks when someone uses rpm -U to upgrade, since it's equivalent
> to running rpm -i followed by rpm -e, which means that the postun
> script is ran last, so the end result is that the instance-specific
> fragment is missing from mainfile after the upgrade.
> How do people usually deal with this kind of situations?
The precise order in update of the scriptlets is


   Run %pre of new package

   Install new files

   Run %post of new package

   Run %preun of old package

   Delete any old files not overwritten by newer ones

   Run %postun of old package

And postun is executed only on update (not install). The scriptlets  take an
argument, the number of package that remains after the script complete: so
you can know if you are in install or update for example and base your
decision on this. Look at this for example


> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20111024/e58f218a/attachment.html>

More information about the Rpm-list mailing list