Overview of the problem
Currently Fedora/RHEL have a semi-defined packaging process so that we can simultaneously distribute multiple release versions of some piece of software.
For example the common case is that you have "foo" packaged and it's NVR would be "foo-1.2" and if it's updated to 2.0 then you release "foo-2.0" and all the users will update from the former to the later, but if you want "foo-2.0" as an optional install (and to not automatically upgrade users with "foo-1.0") then you make the package "foo2.0-2.0" instead so that the user has two different package names "foo" and "foo2.0". There are also cases where you want an upgrade but also to have the ability to keep the old version, and that's often done using a similar but different set of package names like "foo" and "compat-foo1.2".
While this has worked for years, and continues to be the only viable technical solution from the packaging side, it does have limitations at the UI layer (Eg. user which to list "foo"). There are also significant differences in how this is implemented in different packages, which also contribute to the first problem.
Proposed solution
Yum would have a plugin or core feature to add a "multi" sub-command (better names will be considered) which will be able to install and work with multiple versions of the "same upstream", installed at one time. This feature will allow packagers/users to have many versions of a single package installed at the same time, in a standardized way. Although the original push was made by Ruby developers, other programmers/packagers can also benefit from this.
How this sub-command will work different from the top-level commands (feel free to comment on differences):
multi List Command
- "list foo" will show all SU (same upstream) packages for foo. Eg. "foo" "compat-foo1.2" "foo2.0"
multi Install Command
- "Install foo" will not upgrade any installed SU (same upstream) package foo.
- "Install foo" will not remove any installed SU package foo.
- "Install foo" will (by default) install the default (likely the latest) version "SU foo".
- May have options to more easily install other versions.
multi Update Command
- "Upgrade foo" should upgrade all "SU foo" pacakges.
multi Remove Command
- "Remove foo" could remove the oldest, the newest or all "SU foo" packages. Likely have some way to do at least 1 of the former and the later.
- "Remove foo" should make it easier to remove specific "SU foo" packages.
A simple list of User commands
Let's assume this use case:
- We have package "foo", that is to be installed in multiple versions
- User has already installed the official "foo" package (let's say version 1.2.3) from Fedora repositories.
- User has configured yum repos that contain various different versions of "foo": foo1.0-1.0.0, foo-1.2.3, foo1.3-1.3.5
- User runs "yum multi install foo", now nothing happens????
- User runs "yum multi install foo-1.0.0", now foo1.0-1.0.0 will be installed.
- User runs "yum multi upgrade foo", now new versions of "foo" and "foo1.0" will be checked for.
- User runs "yum multi remove-all foo", now both foo and foo1.0 are removed.
- User runs "yum multi install foo", now foo1.3-1.3.5 will be installed (unless we take the "foo" package to mean, install that as a default????).
- User runs "yum multi install foo", now nothing happens.
...more?
Standard Yum Commands
Generally, standard Yum commands will be unaware of multi-installed versions. So you could still "yum remove foo1.2". For any commands that need multi. version UI treatment, they should be added to the new sub-command.
Recognizing this is all very drafty
- A lot of the above behaviour can be changed, and is guesses for what is "best" ... speak up sooner if you want it to change.
- While the code can deal with some amount of the current non-standardization, it will be much better to have more guidance/standardization on this so we don't have "foo1.2" "compat-bar1.2" "baz_1.2" etc.
- This is all meant for UI, to make it easier on the user. So rpm requires/conflicts/etc. will still use "foo1.2 <= 1.2.9" etc.