rpm: Add legacy runtime packages support

[dmik]

Many dynamic libraries use versioning in DLL names to express incompatible ABI changes (i.e. if the old version is named libxyz1.dll, the new one becomes libxyz2.dll and so on). This way, an old application, built against libxyz1.dll continues to work even when libxyz2.dll gets installed.

Unfortunately, RPM doesn't normally allow two versions of the same package to co-exist even if the names of provided files differ. So the old DLL (regardless of its name) is removed when a newer package is installed. This obviously breaks old applications.

The traditional solution used by RPM-based systems is to provide legacy packages with different names (like libxyz-legacy or libxyxz-compat which include old versions and, due to different package names, may co-exist with the newer packages. However, this approach has its pitfalls:

1. A separate .spec file is required for the legacy version (which requires a separate rpmbuild run etc).
2. If you have more than one legacy version to maintain, you will have to come up with as many separate .spec files and unique package names as you have legacy versions.

This is time consuming and boring, given that all you need from the legacy package is the runtime DLL (which is already built, tested and works).

Another possible approach that is also frequently used is to rebuild all applications involving the given software against the new version and release new RPMs for them. But it is also not ideal:

1. There may be quite a lot of such applications.
2. Some applications may be not ready for the new version and require some work.

So this is also time consuming and boring.

This ticket is to introduce a different solution: automatically create legacy sub-packages within the main package that will take previously built DLLs and just repack them. This requires almost zero work from the package maintainer each time when the library ABI changes in an incompatible way.

[dmik]

The idea is to involve our source:/rpmbuild-bot script to do half of the work (in particular, extract old DLLs from RPMs stored in the release repository) and do the other half using RPM macro magic. This idea requires the maintainer to do just two simple things:

1. Add an entry to a special variable RPMBUILD_BOT_LEGACY_xxx in rpmbuild-bot-env.cmd.sh (where xxx is the .spec and main package name).
2. Add a %legacy_runtime_packages macro to the .spec file.

The rest is done in a completely automated manner when a normal rpmbuild-bot run is made to build the given .spec file. Note that this approach allows to create as many legacy packages as needed: only step 1 is to be repeated for any additional package.

The respective changes to rpmbuild-bot are committed in r949. A real-life example is the libvpx.spec​ fiie at r950 (check line 53). The respective changes to RPM will be attached here as diffs. The Wiki documentation describing the whole process for package maintainers will appear shortly after.

[dmik]

Magic script for %legacy_runtime_packages, should go to /@unixroot/usr/lib/rpm

[dmik]

Diff for /@unixroot/usr/lib/rpm/macros

[dmik]

Diff for /@unixroot/usr/lib/rpm/platform/i686-os2-emx/macros

[dmik]

Diff for /@unixroot/usr/lib/rpm/platform/pentium4-os2-emx/macros

[dmik]

Yuri, as usual, the changes for platform macros must be applied to ALL platforms, not only i686 and pentium4 (those two are here because they are the only ones we currently use).

[dmik]

And here is the packager's instruction: ​http://trac.netlabs.org/rpm/wiki/RpmHowToPackagers#Generatinglegacyruntimepackages

[Yuri Dario]

rpm: add legacy runtime packages support. ticket#228.
Committed revision r953.

[dmik]

It turned out that there is a design flaw in RPM. If some %package overrides Version: and Release: tags, the new values will be used further in .spec (including in %setup processing). More details are here: ​https://www.redhat.com/archives/rpm-list/2000-October/msg00218.html.

In our case %setup -n in blocks of code downloading sources from SVN/Git/etc is affected since we use %{version} and %{release} there. This leads to incorrectly named subdirectories in the BUILD tree (and in the ZIP files we generate out of them).

The only workaround is to store old version and release values in some macros and then use these new macros instead of %{version} and %{release} (including %setup as in our case). This is what a new version of find-legacy-runtime.sh​ (attached next) does. It automatically stores the original values in global macros called %{main_version} and %{main_release} respectively before redefining them (to an old version of the legacy package). These macros can then be used across the .spec file in place of the originals.

[dmik]

Updated version

[dmik]

Yuri, the commit for the updated version: Define %main_version and %main_release to overcome RPM design flaw.

[Yuri Dario]

rpm: add legacy runtime packages support. ticket#228.
Committed revision r956.

[dmik]

r972 contains a small cleanup.