#198: cabal install foo should upgrade foo if there's a newer version ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): See also #168 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/198#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#198: outline for revamp of "cabal install" and upgrade behavior ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by ijones): * summary: cabal install foo should upgrade foo if there's a newer version => outline for revamp of "cabal install" and upgrade behavior Old description:

As in #168

if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0

1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that.

New description: I'm consolidating #168 and #197 here. = Use cases = * "cabal install world --deep" (upgrades all packages, whether required or not) * do we delete obsolete packages too? * "cabal install world" (upgrades only "interesting" packages and any required upgrades) * "cabal install foo" (upgrades foo and any required upgrades from foo) * "cabal install foo --deep" (upgrades foo and all its dependencies whether required or not) = Definitions = * '''Interesting packages''' are packages that a user specifically requests, rather than a package that's installed because of a dependency. * '''Obsolete packages''' are packages which were installed as a dependency on an interesting package, but are no longer depended on by any interesting package. * '''required upgrades''' - if the new version of foo requires a new version of Bar, then we are required to upgrade bar. = behavior of "install foo" = if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that. = background from duncan re gentoo = I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use. So at the moment the behaviour is: {{{ cabal install foo }}} means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies cabal install foo-1.1 then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198). {{{ cabal upgrade }}} means upgrade all upgradable packages. Presumably we upgrade them in dependency order. There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed. One data point that I am familiar with is gentoo's package manager. It has a number of variations: {{{ emerge foo }}} means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested. {{{ emerge foo --update }}} changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version. This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed. {{{ emerge foo --deep }}} This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo. There are also a couple meta-packages. One emerge world which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target. So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}} -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/198#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#198: outline for revamp of "cabal install" and upgrade behavior ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Old description:

I'm consolidating #168 and #197 here.

= Use cases = * "cabal install world --deep" (upgrades all packages, whether required or not) * do we delete obsolete packages too? * "cabal install world" (upgrades only "interesting" packages and any required upgrades) * "cabal install foo" (upgrades foo and any required upgrades from foo) * "cabal install foo --deep" (upgrades foo and all its dependencies whether required or not)

= Definitions = * '''Interesting packages''' are packages that a user specifically requests, rather than a package that's installed because of a dependency. * If someone specifies a version number, is that version itself "interesting"? * '''Obsolete packages''' are packages which were installed as a dependency on an interesting package, but are no longer depended on by any interesting package. * '''required upgrades''' - if the new version of foo requires a new version of Bar, then we are required to upgrade bar.

= Niggly Questions = * Rebuilding packages * If Foo depends on Bar, and Bar gets upgraded for whatever reason, should we rebuild Foo, even if it wasn't upgraded, so it uses the new Bar? * This obviously could require rebuilding all the way up the dependency tree. * Deleting packages: * Do we delete obsolete packages? * If we rebuild packages as above, do we delete old versions of uninteresting packages, considering them obsolete? * Do we delete old versions of interesting packages?

= behavior of "install foo" =

if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0

1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that.

= background from duncan re gentoo = I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use.

So at the moment the behaviour is:

{{{ cabal install foo }}}

means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies cabal install foo-1.1 then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198).

{{{ cabal upgrade }}}

means upgrade all upgradable packages. Presumably we upgrade them in dependency order.

There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed.

One data point that I am familiar with is gentoo's package manager. It has a number of variations:

{{{ emerge foo }}}

means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested.

{{{ emerge foo --update }}}

changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version.

This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed.

{{{ emerge foo --deep }}}

This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo.

There are also a couple meta-packages. One emerge world which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target.

So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}}

New description: I'm consolidating #168 and #197 here. = Use cases = * "cabal install world --deep" (upgrades all packages, whether required or not) * do we delete obsolete packages too? * "cabal install world" (upgrades only "interesting" packages and any required upgrades) * "cabal install foo" (upgrades foo and any required upgrades from foo) * "cabal install foo --deep" (upgrades foo and all its dependencies whether required or not) = Definitions = * '''Interesting packages''' are packages that a user specifically requests, rather than a package that's installed because of a dependency. * If someone specifies a version number, is that version itself "interesting"? * '''Obsolete packages''' are packages which were installed as a dependency on an interesting package, but are no longer depended on by any interesting package. * '''required upgrades''' if the new version of foo requires a new version of Bar, then we are required to upgrade bar. * '''Minimal upgrade''' do the minimal necessary installs/upgrades to install a target package. This means prefering installed packages to packages from hackage even if the version on hackage is newer. * '''Maximal upgrade''' do the maximal upgrades to install a target package. So all dependencies are upgraded too, even if later versions are not required. This means prefering the latest available package irrespective of wether some version is already installed. = Niggly Questions = * Rebuilding packages * If Foo depends on Bar, and Bar gets upgraded for whatever reason, should we rebuild Foo, even if it wasn't upgraded, so it uses the new Bar? * This obviously could require rebuilding all the way up the dependency tree. * Deleting packages: * Do we delete obsolete packages? * If we rebuild packages as above, do we delete old versions of uninteresting packages, considering them obsolete? * Do we delete old versions of interesting packages? = behavior of "install foo" = if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that. = background from duncan re gentoo = I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use. So at the moment the behaviour is: {{{ cabal install foo }}} means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies cabal install foo-1.1 then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198). {{{ cabal upgrade }}} means upgrade all upgradable packages. Presumably we upgrade them in dependency order. There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed. One data point that I am familiar with is gentoo's package manager. It has a number of variations: {{{ emerge foo }}} means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested. {{{ emerge foo --update }}} changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version. This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed. {{{ emerge foo --deep }}} This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo. There are also a couple meta-packages. One emerge world which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target. So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}} -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/198#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#198: outline for revamp of "cabal install" and upgrade behavior ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ---------------------------------+------------------------------------------ Comment (by duncan): The current behaviour is this: {{{ $ cabal install foo }}} means install the latest version of foo. If the latest version is already installed (and it has consistent dependencies and no broken dependencies) then it does nothing. If installing foo involves installing other packages then prefer to use any versions that are already installed. This is the minimal upgrade. {{{ $ cabal upgrade foo }}} means install the latest version of foo. The difference from the install command is that for dependencies of foo it prefers the latest available version rather than the installed versions. This is the maximal upgrade. {{{ $ cabal upgrade }}} means upgrade for all the packages currently installed. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/198#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects