This is more of a note to self about a somewhat surprising behaviour but just in case someone else finds it useful I thought I might as well put it out there.

I stumbled onto a puzzling situation recently where I was installing (specifically upgrading an already installed earlier version of) one of our packages in a dev environment and ended up with a set of duplicated files. Everything worked all right with a Deb package, but RPM upgrade produced duplicate links to Jars in HDP’s Hadoop lib directory like so:

├── somelib-1.0.0.jar
└── somelib.jar

So ended up with both versioned and unversioned copy of the jar file.

We have a post-install maintainer script that creates those links for all jar files in our application’s lib/ directory.

There was a recent change to the package to install the versioned jar files into a separate directory and use the alternatives system to maintain unversioned links in our app’s lib/ directory. All good, but why was I ending up with both?

Turned out it’s all due to ordering of the actions during a package upgrade. In deb-based system the order is (in a simple case):

  1. old package: prerm
  2. new package: preinst
  3. new package: files unpacked
  4. old package: postrm
  5. old package: files removed
  6. new package: postinst

In RPM-based system though, the order is:

  1. new package: pretrans
  2. new package: pre (preinst)
  3. new package: files unpacked
  4. new package: post (postinst)
  5. old package: preun (prerm)
  6. old package: files removed
  7. old package: postun (postrm)
  8. new package: posttrans

So the post-install script runs when both old and new files are in place! And since it just loops through all files in that directory, it will just eagerly create links to both versions!

Leave a comment

Your email address will not be published. Required fields are marked *