From Fedora Project Wiki
Line 33: Line 33:
* marked as parallel-installable (by some kind of virtual provide maybe) or
* marked as parallel-installable (by some kind of virtual provide maybe) or
* marked by the plugin locally as parallel-installed packages?
* marked by the plugin locally as parallel-installed packages?
Each way can distinguish the normal and parallel-installed packages and therefore can treat them differently (speaking of updating/uninstalling, etc.)
Each way can distinguish the normal and parallel-installed packages and therefore can treat them differently (speaking of updating/uninstalling, etc.). Again, I'm not completely sure about the consequences here.
* The first option would mark the package parallel-installable, banning it from being installed as a system version.
* The second option might be more flexible (all the packages from all sources would be parallel-installable), but leaving multiple repositories with such packages enabled permanently would result in "yum update" wanting to update system packages to the latest found version. The first option would allow users to leave the repositories enabled permanently without this problem.

Revision as of 07:27, 17 September 2012

Overview

Yum parallel-install plugin should be able to install and work with multiple versions of the same package, installed at one time. This feature will allow dynamic language developers to have many versions of a single package installed at the same time, as they are used to. Although the original target were only Ruby developers, programmers from other dynamic languages will also benefit from this.

A Simple Use Case

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" (let's say version 1.2.3) from Fedora repositories.
  • User installs the yum parallel-install plugin.
  • User has configured yum repos that contain various different versions of "foo": 1.0.0, 1.2.3, 1.3.5
  • User runs "yum parallel-install foo".

Now what?

Parallel-install Command

  • When invoked interactively, parallel-install should ask user which version(s) he wants to install. Non-interactively, it should parallel-install the newest available version.
  • Parallel-installed versions mustn't replace the system versions. In the above example, choosing version 1.2.3 should end in an error.

Update Command

  • Do we need a parallel-update command? Probably not, but I'm not sure about the consequences here.
  • How will parallel-installed versions get updated? Ideally, updating should keep the same versions and only update releases. E.g. when "foo" 1.0.0-1 is installed, it will be updated by foo-1.0.0-2, but not by foo-1.0.1-1 or foo-1.0.1-2.

Parallel-remove Command

  • Normal "yum remove" shouldn't touch any parallel-installed packages.
  • Parallel-remove should give users the opportunity to choose which version(s) to uninstall. Invoked non-interactively, it should remove the highest parallel-installed version (maybe an option for removing all parallel-installed options would be nice).

Standard Yum Commands

Generally, standard Yum commands shouldn't touch parallel-installed versions.

  • Most importantly, "yum update" shouldn't remove older versions of parallel-installed packages.
  • Packages installed via "yum install" should still follow the normal update path.

Recognizing Parallel-install Packages

Should the packages be

  • marked as parallel-installable (by some kind of virtual provide maybe) or
  • marked by the plugin locally as parallel-installed packages?

Each way can distinguish the normal and parallel-installed packages and therefore can treat them differently (speaking of updating/uninstalling, etc.). Again, I'm not completely sure about the consequences here.

  • The first option would mark the package parallel-installable, banning it from being installed as a system version.
  • The second option might be more flexible (all the packages from all sources would be parallel-installable), but leaving multiple repositories with such packages enabled permanently would result in "yum update" wanting to update system packages to the latest found version. The first option would allow users to leave the repositories enabled permanently without this problem.