Motivation:

The original request is described here:

https://bugzilla.redhat.com/show_bug.cgi?id=845247

The core of the request is following: Ruby developers are used to a versioning schema where multiple versions of one package can co-exist on the system simultaneously. In such schema adopted by rpm, upgrading of each package version would happen only on the basis of release number.

Please note that this feature is targeted only on Fedora, considering it to be a development platform. Possible application for RHEL has yet to be discussed with PM.

Specific description and use cases:

Please note that following text is related only to those packages which will be marked to behave this way by their maintainers. Also users will have to enable this functionality (details about these requirements are below)

Storing package in repositories

  • note that this part is more of a question for repo policy, it's not focus of this document. Therefore the decision if a specific version/release of the package should be in a repo is up to the maintainer of that repo
  • Technically speaking, it is perfectly possible for the repo to store even old releases of various versions since yum/dnf will always pick the latest available

General notes

  • listing the package (yum list) will display all versions/releases available. In this way the behavior shall be the same as it is now

Package foo not installed on a system

  • installing the package will install only the latest release of the latest version
  • installing specific version of specific package will be possible upon explicit request, for example by specifying complete NVR which user wants to install. In such case the specific version has to exist.

Package foo already installed on a system

  • upgrading the package:
    • upgrade will check each installed version of the package and look for newer releases. If there are some, it will mark these versions
    • upgrade will check for newer versions of the package. If there are some, the latest will be installed in its latest release
    • it will be possible to install specific version of the package (other than the latest) by specifying it, for example by complete NVR. In such case the specific version has to exist.
  • deleting the package
    • all versions of the package will be uninstalled
    • it will be possible to uninstall only specific package by specifying it, for example by means of complete NVR

Proposed solution:

spec file:

new tag, called for example UpgradeType?. Possible values shall be:

  • upgrade-all: upgrade package whenever epoch, version or release is bumped (this is current default behavior)
  • upgrade-release: upgrade package when release is bumped. Otherwise just install the new one. This value will switch to the behavior described above.
  • upgrade-none: this is basically behavior of installonly packages. Always install new version but leave all old versions untouched

In terms of this document, upgrade means that the new package is installed while the old version is removed, i.e. the new version replaces the old version rather than coexisting with it.

rpmbuild:

Implement support for the new tag. This functionality will be disabled by default, only a specific config option / argument of rpmbuild will enable it. Support for this new tag will mean only that the value specified in spec file will be transferred into header of created RPM file. If the functionality is disabled, the value won't be transferred into the header even if specified in spec file, thus making the package backwards compatible.

rpm:

Implement support for the new tag in RPM header.

createrepo and similar tools

Implement support for the new tag in RPM header: if enabled, the value from RPM header will be transferred into repository's metadata sqlite database so it can be further used by yum/dnf.

dnf:

Support functionality of the new UpgradeType? tag as described above. Support for this tag will be turned off by default and user will be able to turn it on on a per-repo basis.

yum:

same as dnf

Main points of this approach:

User will have control over this functionality, he shouldn't be surprised why upgrades behave differently for some repositories. Also maintainer will have control over this functionality as well. Package will need to be explicitly marked by the UpgradeType? tag for the new versioning to be enabled. This way we can ensure that both maintainer and user will "agree" that the new versioning will be applied to the package.

Note that the functionality will be transferred from spec file to packages by RPMbuild and the default behavior will be not to activate this feature. Also the default behavior of yum/dnf/rpm will be to assume standard upgrade policy if the tag is not present in header of RPM file/repository metadata. This way we will ensure that the new approach will be 100% backwards compatible with current packages.

Security concern:

One security concern was raised about this approach: if the user can configure yum to leave old packages on the system, it will ultimately lead to Fedora being designated as not secure (even though users are responsible for this problem). This concern is addressed by package being marked for the new update schema by maintainer.

Also please note that until explicitly specified, the new UpgradeType? tag won't be transferred into package headers and subsequently repo metadata. This means the feature can remain disabled for Fedora main repos until FESCO decides that it is safe to activate it (probably with some sort of policy in place?). This fully addresses the security concern.

Possible issues:

When upgrading from older releases, some issues might occur considering that older releases of yum/dnf will not support the new package header. It should not be causing any problems other than until the new version of yum/dnf is installed, packages using this feature will be fully upgraded (not leaving the older version behind). Considering that the same behavior will be experienced before user manually configures yum to use this feature on some repos, it shouldn't be that much of a problem.