implement cabal upgrade (installs new versions of all packages) #190

Closed
bos opened this Issue May 24, 2012 · 3 comments

Comments

Projects
None yet
1 participant
@bos
Contributor

bos commented May 24, 2012

(Imported from Trac #197, reported by @SyntaxPolice on 2007-12-18)

See continued discussion.

much like apt-get, we should have a way to upgrade all of the packages to the latest version.

"cabal upgrade" is probably a good name.

@bos

This comment has been minimized.

Show comment Hide comment
@bos

bos May 24, 2012

Contributor

(Imported comment by @dcoutts on 2007-12-18)

See also #168

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2007-12-18)

See also #168

@bos

This comment has been minimized.

Show comment Hide comment
@bos

bos May 24, 2012

Contributor

(Imported comment by @SyntaxPolice on 2007-12-18)

Should be done:

Mon Dec 31 13:39:53 PST 2007 ijones@…

  • Added upgrade command cabal upgrade installs the latest version of any currently installed package.
M ./Hackage/Dependency.hs -2 +59 M ./Hackage/Setup.hs +9 A ./Hackage/Upgrade.hs M ./Main.hs +10 M ./cabal-install.cabal +3
Contributor

bos commented May 24, 2012

(Imported comment by @SyntaxPolice on 2007-12-18)

Should be done:

Mon Dec 31 13:39:53 PST 2007 ijones@…

  • Added upgrade command cabal upgrade installs the latest version of any currently installed package.
M ./Hackage/Dependency.hs -2 +59 M ./Hackage/Setup.hs +9 A ./Hackage/Upgrade.hs M ./Main.hs +10 M ./cabal-install.cabal +3
@bos

This comment has been minimized.

Show comment Hide comment
@bos

bos May 24, 2012

Contributor

(Imported comment by @dcoutts on 2007-12-31)

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
Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2007-12-31)

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

@bos bos closed this May 24, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment