Re: patch applied (cabal-install): Use user installs by default

On Mon, 2007-05-07 at 09:20 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
Fri May 4 03:46:52 PDT 2007 Duncan Coutts
* Use user installs by default So it "Just Works"tm without needing extra options or sudo fiddling. If you care you can still do sudo fiddling and --global-install This is inconsistent with Cabal and ghc-pkg, which both use global installs by default. At the time we felt that global installs were the more common case. I know this isn't a clear-cut issue though, and there are good arguments on both sides. For example, one could argue that only the system's package manager should install packages globally, so since we're bypassing the system package manager we should default to user installs.
However, I'm more concerned that we are consistent, and avoid surprising behaviour where possible.
The surprising behaviour I was trying to avoid was that by default it'd fail with an unhelpful error message. Having it work seems to be a better default. When doing manual, configure, build, install steps people are familiar with the notion that the install step needs to be done as root. When we are installing a whole set of packages automagically we don't quite have the same connection to the individual build steps and we kind of expect things to "Just Work"tm without a great deal of intervention. The only way we can do this is if you always run cabal-install as root. We'd have to make it clearer to people through the command line UI that this is the thing to do. This is also a slightly thing to get right, since if the user runs cabal-install update as non-root then the package db gets downloaded to their $HOME/.cabal-install/packages but if you then do cabal-install install as root then /root/.cabal-install/packages or /var/cache/cabal-install/packages probably is not up to date. As it happens, I'm not sure that --global by default for ghc-pkg and --user by default for cabal-install isn't right. The difference is in who is likely to be using the command and what level of control they expect. I'm cc'ing cabal-devel. Hopefully we can get some more opinions on this. Duncan

Duncan Coutts wrote:
On Mon, 2007-05-07 at 09:20 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
Fri May 4 03:46:52 PDT 2007 Duncan Coutts
* Use user installs by default So it "Just Works"tm without needing extra options or sudo fiddling. If you care you can still do sudo fiddling and --global-install This is inconsistent with Cabal and ghc-pkg, which both use global installs by default. At the time we felt that global installs were the more common case. I know this isn't a clear-cut issue though, and there are good arguments on both sides. For example, one could argue that only the system's package manager should install packages globally, so since we're bypassing the system package manager we should default to user installs. However, I'm more concerned that we are consistent, and avoid surprising behaviour where possible.
The surprising behaviour I was trying to avoid was that by default it'd fail with an unhelpful error message. Having it work seems to be a better default.
When doing manual, configure, build, install steps people are familiar with the notion that the install step needs to be done as root. When we are installing a whole set of packages automagically we don't quite have the same connection to the individual build steps and we kind of expect things to "Just Work"tm without a great deal of intervention.
The only way we can do this is if you always run cabal-install as root. We'd have to make it clearer to people through the command line UI that this is the thing to do. This is also a slightly thing to get right, since if the user runs cabal-install update as non-root then the package db gets downloaded to their $HOME/.cabal-install/packages but if you then do cabal-install install as root then /root/.cabal-install/packages or /var/cache/cabal-install/packages probably is not up to date.
As it happens, I'm not sure that --global by default for ghc-pkg and --user by default for cabal-install isn't right. The difference is in who is likely to be using the command and what level of control they expect.
I'm cc'ing cabal-devel. Hopefully we can get some more opinions on this.
We certainly shouldn't advocate running cabal-install as root (or should we? isn't emerge typically run as root in Gentoo?). I'm concerned that the unsuspecting user might end up with a mixture of globally-installed and locally-installed packages, leading to confusion later on. (See [1] for example) I think this can be solved with decent diagnostics. e.g.: $ cabal-install foo You don't have permission to install packages globally (for all users). Either: run cabal-install as root, or add the --user flag to install packages for the current user only. cabal-install could drop its permissions for the non-install steps, perhaps. Replace "as root" with "as administrator" for Windows. [1] http://gimbo.org.uk/blog/2007/04/27/haskell-packages-gotcha-global-vs-per-us...

On Thu, 2007-05-10 at 09:25 +0100, Simon Marlow wrote:
We certainly shouldn't advocate running cabal-install as root (or should we? isn't emerge typically run as root in Gentoo?).
Yes, gentoo's emerge and all other system packager tools I know of run as root (apt, yum etc).
I'm concerned that the unsuspecting user might end up with a mixture of globally-installed and locally-installed packages, leading to confusion later on. (See [1] for example)
That one looks like it could be explained with nicer diagnostics from ghc. Eg it could say which package version it was using (and perhaps which package db it was from), like it currently has a nice diagnostic if you try and use a module that is hidden. Especially if the package db is inconsistent (eg files or deps missing) the user could be told about that. There are quite a number of ways of corrupting the package db and getting confusing errors as a result.
I think this can be solved with decent diagnostics. e.g.:
$ cabal-install foo You don't have permission to install packages globally (for all users). Either: run cabal-install as root, or add the --user flag to install packages for the current user only.
This is nice, though actually doing these checks is not completely trivial. To be accurate we would want to check if the directory(s) we would install into are writable and if the global package.conf file is writable. Checking the latter is a bit dodgy since cabal isn't supposed to know about the existence of that file.
cabal-install could drop its permissions for the non-install steps, perhaps. Replace "as root" with "as administrator" for Windows.
Sounds like scary posix stuff :-) Do we have functions for changing user / dropping privileges ? I think we should check what the equivalent perl, ruby, python, erlang package distribution systems do. Duncan

On Thu, May 10, 2007 at 09:25:41AM +0100, Simon Marlow wrote:
$ cabal-install foo You don't have permission to install packages globally (for all users). Either: run cabal-install as root, or add the --user flag to install packages for the current user only.
cabal-install could drop its permissions for the non-install steps, perhaps. Replace "as root" with "as administrator" for Windows.
Alternatively, cabal-install -rsudo foo or cabal-install -rootcmd=sudo foo (as a user) could call "sudo whatever" when it needs to do something as root. This would probably mean re-executing itself (or a separate binary) with an --I've-built-it-just-install-it-from=/tmp/... flag. This is what various Debian tools do, although it's slightly nicer in those cases as they are just calling a couple of shell commands. Thanks Ian

Ian Lynagh wrote:
On Thu, May 10, 2007 at 09:25:41AM +0100, Simon Marlow wrote:
$ cabal-install foo You don't have permission to install packages globally (for all users). Either: run cabal-install as root, or add the --user flag to install packages for the current user only.
cabal-install could drop its permissions for the non-install steps, perhaps. Replace "as root" with "as administrator" for Windows.
Alternatively,
cabal-install -rsudo foo or cabal-install -rootcmd=sudo foo
(as a user) could call "sudo whatever" when it needs to do something as root. This would probably mean re-executing itself (or a separate binary) with an
--I've-built-it-just-install-it-from=/tmp/...
flag. This is what various Debian tools do, although it's slightly nicer in those cases as they are just calling a couple of shell commands.
Looks fine to me. Cheers, Simon
participants (3)
-
Duncan Coutts
-
Ian Lynagh
-
Simon Marlow