[Hackage] #688: adopt XDG basedir spec

[Hackage]

#688: adopt XDG basedir spec
---------------------------------+------------------------------------------
  Reporter:  guest               |        Owner:         
      Type:  enhancement         |       Status:  new    
  Priority:  low                 |    Milestone:         
 Component:  cabal-install tool  |      Version:  1.8.0.4
  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
 should.

 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
 installs.

 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.

 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