[Haskell-cafe] Experiments in Haskell Packaging

Chris Dornan chris at chrisdornan.com
Fri Jan 6 17:44:06 CET 2012

Thanks Sanket,
That ticket <https://github.com/haskell-hub/hub-gen/issues/8>  on the need
for user-space installs is a model of clarity.
I don't have any problem with installing the tools into user-land - this
will be true of all of the components in the justhub distro - provided you
start with the source code.
I want so solve this problem, but it may have be done with non-RPM
I will have to think about this a bit and get back to you.
Thanks again!
From: Sanket Agrawal [mailto:sanket.agrawal at gmail.com] 
Sent: 06 January 2012 00:56
To: Chris Dornan
Cc: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Experiments in Haskell Packaging
Hi Chris,
I have created a ticket request for user-space install of GHC and haskell
platform. For some of us, development environment is very similar to
production environment (minus the dev tools) to keep the deployment
procedures consistent, and simple. So, we don't have root privileges in dev
environment too. But, this is not really a big deal as all of the
development tools that I am familiar with, can be installed in user-land in
user-defined locations.

On Thu, Jan 5, 2012 at 5:15 AM, Chris Dornan <chris at chrisdornan.com> wrote:
Hi Sanket,
If you like you can put a ticket into the issue tracker
<https://github.com/haskell-hub/hub-gen/issues>  (otherwise I will do it
I am sorry that you have had to go to such lengths to get Haskell working on
your systems.
Unfortunately I don't think it is going to be straightforward to make the
packages relocatable. 
Could you say a little more about why you need to do this? Do you need a
user-space install?
I had targeted this distribution primarily at development systems and build
servers where I would expect populating /usr/hs with read-only data and code
wouldn't be a problem.
It sounds like you might be immediately better off working directly with the
source code. I can help with this obviously as I have had to solve these
problems. (The REHEL5-supplied gcc and binutils tools are too to build
recent GHC releases, so I use more recent tools, which I also package with
the distribution.)
In the medium/long term It may be easier to address these needs with a
separate 'lite' distribution focused on field-deployment with relocatable
packages, which may as well be user-space deployable too. 
This will need to be researched and could take some time.
If anybody else is interested in this then please get in contact.
Also, if anybody has any other gripes or ideas about how Haskell
distributions generally it would be good to hear.
From: Sanket Agrawal [mailto:sanket.agrawal at gmail.com] 
Sent: 05 January 2012 01:36
To: Chris Dornan
Cc: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Experiments in Haskell Packaging
Hi Chris,
Is it possible to also make the GHC and haskell platform distributions
available as relocatable rpms, instead of HUB packaging? The reason is that
for some of us, when we work in complex production environment which has its
own deployment procedures, we have to deploy it differently. A hard-coded
path like /usr/hs won't work, and a packaging environment that depends on
that hard-coded path won't work either in that case.
I actually downloaded RHEL5 GHC binary rpm from justhub.org, and unpacked it
using rpm2cpio. Then, I ended up doing grep and sed to replace all
occurrences of "/usr/hs" with the path I installed it in. It worked well
except for some caveats - some of the binary/data files such as *.hi seem to
have the hard-coded path in them. That hasn't caused any issues so far,
except for haddock which fails if gcc is called since it is coded to
/usr/hs/bin/gcc (though haddock bash shell has right gcc path coded in it -
I guess it ignores it in favor of the path in some binary file). 
It will be very nice to have what I did above, as relocatable rpms, and
without HUB dependency. That will help with, I suspect, reducing the
duplication of efforts when some of us, who want to use haskell at work, end
up compiling our own binaries for RHEL platform (since glibc on RHEL 5/6 is
older than what ghc-pwd demands). I tried to compile GHC 7.4 on RHEL 5, but
it failed to link because of some GHC bug. That is how I ended up using your
compiled binary with my grep/sed hack. It was a great time-saver. Thank you
for doing this work.
On Tue, Jan 3, 2012 at 7:49 AM, Chris Dornan <chris at chrisdornan.com> wrote:
'Antoine Latter' <aslatter at gmail.com>:

> All of this is in my head, but assuming I already had some sort of
> Linux build-server set up, it would be nice to combine it with your
> work to make it easier to have the build-server run tests against
> multiple versions of GHC/HP. That's all I was getting at.

Working within the Hub framework this is straightforward. If you are using
public releases rather than special builds of the tools then it should be
quite easy.

Supposing you needed to test with Haskell Platform 2011.2.0.1 and

       # install the platform (probably done already)

       sudo yum install haskell-platform-2011.2.0.1-hub

      # create new hub 'test-2011.2.0.1' based this HP

      hub init 2011.2.0.1 test-2011.2.0.1

      # install hexpat-0.19.7 into it

      hub install-into test-2011.2.0.1 hexpat-2011.2.0.1

Repeat as necessary to create your array of test environments.

Now you just have to arrange select the appropriate hub for each test.
Suppose the environment variable $testhubs contains all of your test hubs
('test-2011.2.0.1', etc.), then the following shell command would prime the
tools to successively use each of the test environments on each invocation
of make.

       for h in $testhubs; do HUB=$h make; done

Note that the justhub distribution isn't necessary for this -- you can do it

But it does make it easier.


Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120106/570e0cf3/attachment.htm>

More information about the Haskell-Cafe mailing list