| 413 | | 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: |
| 414 | | |
| 415 | | 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. |
| 416 | | |
| 417 | | 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. |
| 418 | | |
| | 413 | Add a `%legacy_runtime_packages` macro somewhere 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 and `%legacy_runtime_packages` specifics: |
| | 414 | |
| | 415 | 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 to simplify identification purposes and also to make it possible refer to a particular version from other .spec files when necessary. |
| | 416 | |
| | 417 | 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 than the old version. This serves for two purposes: a) to provide smooth package updates with `yum update` (which will simply replace the old `package` with the new `package-legacy-ABI`) and b) to keep other software packages which still depend on the old runtime installable. |
| | 418 | |
| | 419 | 3. The use of the `%legacy_runtime_packages` macro has one side effect: it overwrites the definitions of the standard `%version` and `%release` macros for all sections of the .spec file except the `%package` ones. Normally this is not a problem since these macros are rarely used anywhere besides `%package`. But there is at least one common case where they are typically used: the `%setup` macro. If a source archive uses an unusual directory structure and requires manual unpacking, the setup macro invocation may look like this: `%setup -n %name-%version-%release`. This will not work as expected when `%legacy_runtime_packages` is present (in particular, the setup macro will create a build directory carrying the version of the legacy package rather than the main .spec version). This and all similar problems may be easily fixed by replacing `%version` and `%release` through out the .spec file (excluding the %package sections!) with special macros `%main_version%` and `%main_release` defined by `%legacy_runtime_package` to preserve the original values of the top-level Version: and Release: tags of the .spec file. |
