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 myself). 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. Chris From: Sanket Agrawal [mailto:sanket.agrawal@gmail.com] Sent: 05 January 2012 01:36 To: Chris Dornan Cc: haskell-cafe@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. -Sanket On Tue, Jan 3, 2012 at 7:49 AM, Chris Dornan wrote: 'Antoine Latter' :

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 hexpat-0.19.7: # 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 manually. But it does make it easier. Chris _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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 packaging. I will have to think about this a bit and get back to you. Thanks again! Chris From: Sanket Agrawal [mailto:sanket.agrawal@gmail.com] Sent: 06 January 2012 00:56 To: Chris Dornan Cc: haskell-cafe@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. Thanks, Sanket On Thu, Jan 5, 2012 at 5:15 AM, Chris Dornan 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 myself). 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. Chris From: Sanket Agrawal [mailto:sanket.agrawal@gmail.com] Sent: 05 January 2012 01:36 To: Chris Dornan Cc: haskell-cafe@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. -Sanket On Tue, Jan 3, 2012 at 7:49 AM, Chris Dornan wrote: 'Antoine Latter' :

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 hexpat-0.19.7: # 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 manually. But it does make it easier. Chris _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe