Cabal-1.22 keyed library filepaths

[Edward Z. Yang]

Jens, could file a Cabal bug for the contents of this email?

Edward

Excerpts from Edward Z. Yang's message of 2015-01-18 22:47:23 -0800:
> Hey Jens,
> 
> The motivation for truncating the names and version was to keep
> symbol name sizes manageable even with the addition of the hash,
> while giving at least some hint when working with the symbols
> directly.  It doesn't seem that this rationale applies for library
> names, so it's possible we could separate these (in any case, only
> the hash really matters: the package name/version are included
> in the hash), but we'd have to figure out where in the current codebase
> makes assumptions about this.
> 
> Edward
> 
> Excerpts from Jens Petersen's message of 2015-01-18 17:54:34 -0800:
> > Hi,
> > 
> > I see that with Cabal-1.22, library paths are now of the form:
> > 
> >  /usr/lib64/ghc-7.10.0.20141222/direc_3m6Ew9I164U5MIkATLCdb8/
> > libHSdirec_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so
> > 
> > etc.
> > 
> > Is the 5 character truncation of package names (and no version) necessary?
> > It makes it pretty hard to see at a glance what package a particular
> > directory or file belongs to and seems there is no easy way to work out the
> > package version without referring to the package.conf file/dir.
> > 
> > If possible I would prefer a filepath format like:
> > 
> >  /usr/lib64/ghc-7.10.0.20141222/directory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8/
> > libHSdirectory-1.2.1.1_3m6Ew9I164U5MIkATLCdb8-ghc7.10.0.20141222.so
> > 
> > Would that be feasible/make sense?
> > 
> > Jens