[Hackage] #688: adopt XDG basedir spec
cvs-ghc at haskell.org
Fri May 28 07:10:30 EDT 2010
#688: adopt XDG basedir spec
Reporter: guest | Owner:
Type: enhancement | Status: new
Priority: low | Milestone:
Component: cabal-install tool | Version: 220.127.116.11
Severity: normal | Keywords:
Difficulty: hard (< 1 day) | Ghcversion: 6.10.4
Platform: Linux |
I found this ticket while researching precedents for a related question.
For various reasons I like to build multiple versions of GHC side by side:
Migration between major releases, testing candidate releases. For torture-
testing new hardware, building many copies of GHC at once is better than
e.g. the usual prime testing. I once literally caused a server power
supply to smoke this way; my friend's hardware vendor was in over their
head. They took my GHC test in-house to minimize delivery cycles.
A related piece of de facto convention comes up here: It is crazy to
sprinkle pieces of a system like GHC into separate global locations like
/usr/local/bin, /usr/local/share, unless one will only ever use one
version, with no desire to look under the hood or move the installation.
In other words, I have no issue with Linux or OS X shipping this way, but
major additions should be localized by default. Some are, e.g. TeX. GHC
Fortunately, to avoid Siamese twin installations with accidentally shared
parts, one can use the ./configure --prefix option while building GHC.
Then, it becomes apparent that "cabal install" is the remaining holdout to
ideal version localization. There is a perfect storm of tiny factors
keeping Cabal from gracefully localizing. I wanted to elicit advice before
contributing a fix; this ticket seems to have touched on a key issue.
I did not know about the "--config-file=..." command-line option; I will
start using it in scripts. However, we need a better default for global
In /usr/local I now use a symbolic link from ghc to one of the directories
ghc-6.10.4, ghc-6.12.1, ghc-6.12.2, ghc-6.12.3-rc1. It then appears that I
built GHC using "--prefix=/usr/local/ghc". My ~/.cabal/config file
includes lines like "remote-repo-cache: /usr/local/ghc/packages". This
works, but I've had amusing debates with unix experts on why my symbolic
link is a terrible solution. Basically, when I change this link I pull the
rug out from under any ongoing process that wants to see a consistent
Environment variables are one "right" way to handle this. In short, a
symbolic link is like changing state, while environment variables are like
However, not only does .cabal/config fail to allow external environment
variables, it doesn't allow forms like one sees in its own comments. (Who
reads documentation? We all read sample code.) For example, even though I
see the comment "-- bindir: $prefix/bin" I cannot write "remote-repo-
cache: $prefix/packages". I would prefer to be able to write anything that
would evaluate correctly in a shell to an absolute path, e.g. `which ghc`
or `perl -pe ...` and so forth.
Ideally, a global install would by default use a global location for the
Cabal config file, but we slam back into the original problem: By default
the global install of GHC did not use the --prefix option, so there is no
well-defined location parametrized by the version of GHC. On the other
hand, this isn't so bad, e.g. put everything in
../share/hackage.haskell.org relative to the currently visible ghc. Saves
bandwidth caching packages; if someone hasn't bothered to build ghc using
--prefix, they won't mind the Siamese twin effects with Cabal either.
The simplest change that would help my issue would be to allow both
absolute and relative paths in .cabal/install, with a relative path
relative to the location of `which ghc`. This would "just work" in simple
cases, and allow competing processes to coexist, that chose different
versions of ghc via a custom $PATH alone, with no other flags needed. If
this change was accepted, I wouldn't mind leaving my config file in
~/.cabal. That location is only mildly annoying; as has been noted, we've
already lost the war on keeping that area uncluttered.
However, it just shouldn't matter which authorized user works on a global
install. Relying on ~/.cabal/config for a global install should be viewed
as a bug, as it prevents several admins from cooperating in consistently
maintaining GHC on a shared system.
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/688#comment:6>
Hackage: Cabal and related projects
More information about the cabal-devel