#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