haskell package layout: a proposal

[Magnus Therning]

On 04/12/10 06:37, Mark Lentczner wrote:
> Over on my blog, I've put up a proposal for changing the default layout of installed package pieces:
>
> 	http://mtnviewmark.wordpress.com/2010/12/02/haskell-package-layout/
>
> Thoughts?

As I understand it the main issue you bring up is that

1. It's not possible to install multiple versions of packages containing
   binaries, and/or documentation.
2. It's not possible to install the same version of a package, compiled with
   different compilers (or compiler versions), when that package contains
   binaries and/or documentation.

and as a corollary

3. It IS possible to install multiple version of a package as long as it
only
   contains a library.
4. It IS possible to install the same version of a package, compiled with
   different GHC versions, when that package only contains a library.

Is this correct?

I've come up against this limitation myself when packaging Hackage packages
for ArchLinux in such a way that multiple version could be installed in
parallel.  That actually unearthed another limitation, one that you don't
mention: the documentation index file,
/usr/share/doc/ghc/html/libraries/index.html on my system.  This file can be
rebuilt with /usr/share/doc/ghc/html/libraries/gen_contents_index, but
it only
allows for one entry for each library.

Further splitting up the hierarchy to better deal with multiple versions and
configurations of a package being installed in parallel is probably a good
thing.  However, I don't think the split you make is very likely to be
adopted.

You suggest:

$prefix           -- /usr/local/haskell if --global, and ~/.cabal if --user
  $compiler
    $pkgid
      bin         -- binaries
      lib         -- libraries & .hi files
        include   -- include files
      libexec     -- private binaries
      share       -- data files
      doc         -- documentation
        html      -- html doc
        man       -- man pages

Here are my arguments against this particular hierarchy:

1. I'd argue that Unix administrators expect $prefix to default to
/usr/local.
   Defaulting to adding a new directory under /usr/local for haskell
packages
   is unlikely to be appreciated.
2. As a distro packager I would have to make some considerable changes
to the
   layout during the configure step, or alternatively create a considerable
   number of symlinks, to make things work (think of default $PATH,
manpaths,
   etc).
3. I don't think your comment on per-interpreter directories for Python is
   true.  AFAIK Python only uses that directory for modules, not for
binaries
   and not for documentation.  That would mean that Cabal's current
behaviour
   matches what Python does.  (Please correct me if my understanding of this
   is wrong.)

Personally I would keep the top-level bits the same and instead insert
bits in
the lower levels:

$prefix
  bin
  lib
    $compiler
      $pkgid
        include
  libexec
    $compiler
      $pkgid
  share
    $compiler
      $pkgid
    man
  doc
    $compiler
      $pkgid
        html

Some comments on this:

1. Placing binaries in $prefix/bin increases the likelihood of things just
   working.  Binaries from multiple versions/configurations of a single
   package can be handled by a suffix to the filename itself.  It could be
   useful to be able to instruct Cabal to create a symlink from the basename
   to the full filename (basename-suffix) at install time.
2. Man pages can be dealt with in the same way as binaries, by using
suffixes.
   I have to admit I'm not sure whether this is very standard, but it does
   seem to work.
3. Deleting stuff in this layout would be slightly more work than in yours,
   but not considerably more.

Comments?

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20101204/d677cb5a/attachment.pgp>