[Hackage] #688: adopt XDG basedir spec

Hackage 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:
  Severity:  normal              |     Keywords:         
Difficulty:  hard (< 1 day)      |   Ghcversion:  6.10.4 
  Platform:  Linux               |  

Comment(by Syzygies):

 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
 functional programming.

 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 <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list