From Fedora Project Wiki
(Created page with "== Overview == Yum parallel-install plugin should be able to install and work with multiple parallel versions of the same package, installed at the one time. This feature will...")
 
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Overview ==
== Overview ==
Yum parallel-install plugin should be able to install and work with multiple parallel versions of the same package, installed at the one time. This feature will allow e.g. Ruby developers to have many versions of a single Gem installed at the same time, as they are used to. Although the original target were only Ruby developers, programmers from other (mainly interpreted) languages will also benefit from this.
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 ==
== A Simple Use Case ==
Line 18: Line 18:
=== Update Command ===
=== Update Command ===
* Do we need a parallel-update command? Probably not, but I'm not sure about the consequences here.
* 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 installed 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.
* 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 ===
=== Parallel-remove Command ===
* Normal "yum remove" shouldn't touch them and there should be "yum parallel-remove", which should give user 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).
* 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 ==
== Standard Yum Commands ==
Generally, standard Yum commands shouldn't touch parallel-installed versions.
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.
* 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 ==
== Recognizing Parallel-install Packages ==
Line 31: 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.
 
<span style="color: green;">Update [09/19]: Another way might be to mark whole repos as parallel-install, which wouldn't need any change in packages and it also wouldn't update system packages with packages from other repos, as mentioned above.</span>
 
<span style="color: green;">Update [09/24]: Yet another way might be tracking the origin of the packages. This way, we wouldn't need any marking of packages/repos. Once a package would get installed from the official repo, it would get only updated from there. Same for any package installed from any repo. IMHO this might be the best solution. AFAIK, Ubuntu's aptitude does it that way.</span>

Latest revision as of 07:29, 24 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.

Update [09/19]: Another way might be to mark whole repos as parallel-install, which wouldn't need any change in packages and it also wouldn't update system packages with packages from other repos, as mentioned above.

Update [09/24]: Yet another way might be tracking the origin of the packages. This way, we wouldn't need any marking of packages/repos. Once a package would get installed from the official repo, it would get only updated from there. Same for any package installed from any repo. IMHO this might be the best solution. AFAIK, Ubuntu's aptitude does it that way.