[Hackage] #289: symlink binaries into ~/bin

Hackage trac at galois.com
Sun Aug 3 08:31:05 EDT 2008

#289: symlink binaries into ~/bin
  Reporter:  duncan              |        Owner:                     
      Type:  enhancement         |       Status:  new                
  Priority:  normal              |    Milestone:  Cabal-1.4          
 Component:  cabal-install tool  |      Version:                     
  Severity:  normal              |   Resolution:                     
  Keywords:                      |   Difficulty:  very easy (<1 hour)
Ghcversion:  6.8.2               |     Platform:                     
Comment (by Isaac Dupree):

 Replying to [comment:4 duncan]:
 > Replying to [comment:3 Isaac Dupree]:
 > Most distros set things up so that `~/bin` is in the `$PATH` by default
 (if it exists).

 hmm, I didn't realize.  At least, I've never noticed that happening under
 Gentoo, GoboLinux or Ubuntu (then again, I don't think I actually had a
 `~/bin` when I was on Gentoo, I put things in `~/u/bin` back then).

 > Why would you want unversioned names under `~/.cabal/bin` if that is not
 on your `$PATH` ?

 (1. It's on my `$PATH`)

 2. so that I can explicitly invoke `~/.cabal/bin/alex` without giving a
 version number, maybe?  What I don't want is the "unversioned" feature to
 be combined in an essential way with another feature that I don't want.  I
 suppose I could put my symlink-bindir as `$HOME/.cabal/unversioned-bin`,
 but that seems like it would be messing with cabal's area a bit without
 its permission.

 > I don't think we should ignore a `~/bin` just because it is a symlink.
 Users who don't want the feature can easily turn it off in the

 Only if you tell anyone who installs a binary that they can turn off the
 feature there, and how, and how to clean up the mess that cabal has
 already made... (unless you ask the user first)

 > I'm not sure what you mean about trampling, we're being pretty careful
 not to trample anything. By default we only touch `~/.cabal` and are
 careful with setting symlinks in `~/bin` so that we do not overwrite
 anything created by the user or any other program.

 It's because I'm paranoid about that, because I prefer to have full
 control over what is in my home filesystem structure, separate from what
 programs want to automatically store.  True, the proposed system won't
 delete any important data, so the worst that can happen is that I don't
 notice for a while, it causes a little havoc when some GHC build uses a
 version of Alex that I didn't expect (e.g. if I installed Alex through my
 system's package manager), and eventually I have to figure out what
 happened, clean up the mess, and if I'm feeling lucky, find out how I can
 turn it off in the cabal config file.  This is no figment of my
 imagination -- I only went to such a weird-looking scheme because of
 repeated problems with miscellaneous programs that I maybe only used once
 (it became even worse on Ubuntu where things run even when you don't
 explicitly configure them to, AND make a mess in `$HOME`).  By all means,
 go ahead and do things automatically in Cabal for the users that like
 that, because I've lost all trust in that sort of thing and I've found a
 way to avoid it (so far, I've never had a problem with different programs
 messing with $HOME in ways that they break each other automatically --
 that would be more difficult to deal with :-).  Grudging thanks for
 reminding me never to put anything of my own in `$HOME`, unless it's
 modifying a config-file in `$HOME/.something` that can't be stored

 er, sorry for the rants, did it explain anything?  I think if all programs
 had always been as polite as Cabal is planning to be, I ''might'' have
 appreciated it doing that automatically...

 Anyway, which version are you planning to symlink as the unversioned one?
 The one with the greatest version?  Is there a way to modify that, that'll
 last longer than just changing the symlink target?


Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/289#comment:5>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list