At long last: 2014.2.0.0 Release Candidate 1

[Mark Lentczner]

On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne <svenpanne at gmail.com> wrote:

> The source tarball is missing a few files for hptool:
>

I'll try to catch them the next round... or pull requests on github welcome!

On Thu, Jul 24, 2014 at 4:22 AM, Sven Panne <svenpanne at gmail.com> wrote:

> ...But I'm a bit
> clueless how to proceed from that point: What I actually want is a
> complete installation of the HP under a given prefix.


Your build is using the *genericOS* set up in src/OS/Internal.hs. In the
past, linux/unix distribution packagers have worked from the src tarball,
and when I queired in the past, none said they used the build scripts HP
had, but used their own. And in turn, no one put in any effort over the
last six months to add a build decription using the new build system other
than OS X and Windows.

SO - what you, and we, need is a src/OS/GenericLinux.hs file so that it
does you/we think is the generic layout for where things should live. For
your own, peronsal install, you could start by just hacking on the
*genericOS* structure in src/OS/Internal.hs. That strucutre is currently
set up to build something which is unpacked over /, which is probably what
most people *don't want, *but is agnostic to the variety of layouts
possible.

On Thu, Jul 24, 2014 at 4:48 AM, Sven Panne <svenpanne at gmail.com> wrote:

> Hmmm, it looks like the install paths are hardwired in
> hptool/src/OS/Internal.hs. Do I see this correctly? If yes, that's a
> bit unfortunate, an additional parameter to platform.sh or an
> environment variable would be nice.


Yes - it would need to be added to Main.hs, and then plumbed to the right
point in the code. Sound great.... I can haz pull request plz? (you knew
that was coming... :-)  )


> Furthermore, the executables are
> scattered around:
>
>
>  build/target/usr/local/haskell-platform/2014.2.0.0/lib/alex-3.1.3/bin/alex
>
>  build/target/usr/local/haskell-platform/2014.2.0.0/lib/cabal-install-1.18.0.5/bin/cabal
>
>  build/target/usr/local/haskell-platform/2014.2.0.0/lib/happy-1.19.4/bin/happy
>
>  build/target/usr/local/haskell-platform/2014.2.0.0/lib/hscolour-1.20.3/bin/HsColour
> ...

Normal packages put their binaries below /usr/bin, their
> libs below /usr/lib, their docs below /usr/share/doc etc. How are
> other packagers on this list handling this?
>

My rationale is that if you install things under /usr/bin, /usr/lib,
/usr/share/doc - then it becomes essentially impossible to remove easily:
There are just far too many files in those trees intermingled with files
from other things. Same is true if you do /usr/local/...

My preferred approach is to put the whole installation under one prefix,
say /usr/loca/ghc/ghc-7.8.3/, in there there are /bin, /lib, and /share. As
you point out, this is a pain for PATH... so what I do is have an
"activation" script that symlinks all the executables in that tree up and
over into /usr/bin (or /usr/local/bin). Now clean up is a snap: Remove the
ghc-<version> tree you want gone, and then remove all the symlinks in
/usr/bin and/or /usr/local/bin that are now dangling into it.

Does this make sense for simple "untar, run a script" kind of distributions?

For people packaging for OS distributions, using a host OS package manager,
I suspect they prefer the "overlay it all" approach, because the package
managers take care of the chore of remembering which files go with which
thing and handle uninstallation.

I could easily imagine two or more styles under src/OS for hptool:
PosixLocalTarball.hs, PosixPackaged.hs, Ubuntu.hs, FreeBSD.hs, etc...

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140724/e8ac9153/attachment-0001.html>