Changes between Version 53 and Version 54 of RpmHowToPackagers

Timestamp:

Feb 4, 2017, 4:46:01 PM (7 years ago)

Author:

dmik

Comment:

Generating legacy runtime packages

RpmHowToPackagers

@@ -153 +153 @@
 {{{
 %files
-%defattr(-,root,root,-)
 %{_bindir}/rpm.exe
 %{_mandir}/man8/rpm.8*
@@ -390 +389 @@
 Note that if you don't need any debug info generation at all, simply remove the `%debug_package` macro from your .spec file and debug file generation will be automatically suppressed (all the debug info will be silently discarded from the executable files during the compression phase in such case).
 
+== Generating legacy runtime packages ==
+
+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` will continue to work even when `libxyz2.dll` gets installed. However, this popular deployment approach is not directly supported by RPM (you cannot have two versions of the same package installed at the same time, even if the file names differ).
+
+In order to nicely solve this problem, an extension was added to RPM for OS/2 that allows users to have two incompatible versions of the same runtime DLL installed side by side and at the same time keep the normal package update functionality fully intact. This extension works in a fully automatic manner, provided that the packager uses the source:/rpmbuild-bot script.
+
+Given a package named `package`, the following steps need to be done in order to generate legacy runtime packages with `rpmbuild-bot.sh`:
+
+==== 1. Add a rpmbuild-bot configuration entry ====
+
+Add an entry named `RPMBUILD_BOT_LEGACY_package` to `rpmbuild-bot-env.sh` containing a package specification string in the following format:
+{{{
+ABI|NAME|VERSION-RELEASE|[FILEMASK]|[ARCH]
+}}}
+ABI is the ABI version (normally, a suffix added to the DLL basename to differentiate between incompatible DLL versions), NAME is a name of the old package where to take the DLL from (usually is the same as `package`), VERSION-RELEASE is the version of the old package and FILEMASK is a file mask for runtime DLLs (by default, `*.dll`). You may specify more than one ABI specification (separated by a space) tho this variable if you need to provide more than one version of legacy runtime DLLs.
+
+Given the above information, `rpmbuild-bot` will automatically extract the runtime DLLs from the specified RPM package located in the stable repository (the one specified in a`RPMBUILD_BOT_UPLOAD_REPO_STABLE` variable) and make these DLLs available for `rpmbuild` by storing them in a SOURCES directory of its directory tree.
+
+Note that `rpmbuild-bot` will properly handle all supported target platforms (as specified in `RPMBUILD_BOT_ARCH_LIST`) when extracting old runtime DLLs in order to make sure that the automatically generated legacy sub-package will carry a DLL built for the same target platform as the main package. If an old version of the DLL didn't exist for this platform, `rpmbuild-bot` will fail. In such a case you should force a specific platform of the old DLL to be used for all target platforms of the new package by using an optional ARCH field in the legacy package specification string.
+
+==== 2. Add a magic macro to package.spec ====
+
+Add a `%legacy_runtime_packages` macro just before the `%prep` section of the .spec file. This will cause `rpmbuild` to create a sub-package named `package-legacy-ABI` for each ABI listed in the configuration variable for this package. There are a few things to note about the generated legacy sub-packages:
+
+1. The legacy sub-package will carry a version and release number of the original package (i.e. the package where the legacy runtime DLL is taken from), not the main package version. This is done to for simpler identification purposes and also to refer to a particular version from other .spec files when necessary.
+
+2. The legacy sub-package will have `Provides:` field set to the old version (i.e. the version of the original package) and `Obsoletes:` field set to less or equal to the old version. This serves for two purposes: to provide smooth package updates with `yum update` (it will simply replace the old `package` with the new `package-legacy-ABI`) and also to keep other software packages which still depend on the old runtime installable.
+
+
 == Setting up executable compression ==
 
@@ -408 +436 @@
 
 == OS/2 specific notes ==
+
 While the syntax of .spec files is the same used under Unix, not everything is currently working in the OS/2 port. Also many packages are already built and manually installed: this means RPM is not aware of their presence.