On 14 April 2015 at 13:51, SP wrote:

On 14/04/15 06:42, Magnus Therning wrote:

...

On 14 April 2015 at 02:21, Nicola Squartini wrote:

...

Solving the problem of pandoc and gitit binaries taking so much space, would require splitting the packages in two. [..]

The reasons we don't do that sort of splitting are two:

1. The tool that helps with packaging `clbrepo` doesn't support it, and most importantly

Maybe it is a call for looking into such support. Haskell packages are huge! There has to be a significant population of users which want a lean & mean machine. It takes about 900 MiB of installation size for haskell-conduit. Addressing this will help with adoption.

Patches are always welcome. :)

...

2. splitting into -bin and -dev packages, like in Debian/Ubuntu/..., isn't the norm in Arch

Maybe not -bin and -dev then, but something has to give. I didn't see anything against it in the packaging standards. We can liaise with the core team to find out the Arch-y way for this issue.

We don't really have to include the core team at all. ArchHaskell isn't an official part of Arch so we can do what we want. However, following the path of least surprise would suggest we don't stray too far away from the Arch way. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On 14 April 2015 at 15:19, Bastien Traverse wrote:

Le 14/04/2015 02:20, Nicola Squartini a écrit :

...

Solving the problem of pandoc and gitit binaries taking so much space, would require splitting the packages in two. Right now haskell-pandoc and haskell-gitit are packaged with binaries and modules inside, and the module part depend on all the other packages, including GHC. If we split each of them into two, say pandoc (binaries) and haskell-pandoc (modules), then you could just install the binaries without having to depend on GHC.

Thanks, that's the information I was looking for. I hadn't understood that pandoc and gitit could be split in different parts from their regular installation instructions. How does one do so?

IIRC, the regular installation doesn't support it (i.e. via Cabal). What we need is specific recipes to package tools and lib parts into separate packages, i.e. a split package. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On 14/04/15 13:10, Magnus Therning wrote:

Patches are always welcome. :)

Naturally. If I find time I'll give it a shot.

We don't really have to include the core team at all. ArchHaskell isn't an official part of Arch so we can do what we want. However, following the path of least surprise would suggest we don't stray too far away from the Arch way.

I'm aware and it would be ok to take whatever route suits ArchHaskell best. But given this is targeted at Arch and I presume everyone here wants Haskell to flourish, it might pay dividends in the future to have a design which is in harmony with Arch. Since the design to-date of Arch might have not had to deal with large packages, they may have not catered for this problem and thus no "path of least surprise" for us to follow. It may be worthwhile to have their take on this, a solution they agree is in line with Arch. This way we will also be following a path of least surprise for us, in case they decide in the future to work scenarios like ours differently. Who knows.. in a future where everything is running on Haskell, ArchHaskell might need to be merged in their "extra" repos! -- SP

On 14/04/15 22:29, Magnus Therning wrote:

Just playing around a little with one of the packages currently in the repo comprising both a lib and a binary resulted in the attached PKGBUILD (shake). It might be close to what a solution could look like.

Btw, is there a repo for the PKGBUILD files? -- SP

Do the current packages include the dynamically linkable libs? If the apps are going to require the installation of the Haskell libs they depend on anyway, maybe having them dynamically link to the Haskell libs, rather than statically link them in, would save a good chunk of disk space, not to mention linking time. On Tue, Apr 14, 2015 at 4:51 AM, SP wrote:

I am for some kind of splitting. See below.

On 14/04/15 06:42, Magnus Therning wrote:

...

On 14 April 2015 at 02:21, Nicola Squartini wrote:

...

Solving the problem of pandoc and gitit binaries taking so much space, would require splitting the packages in two. [..]

The reasons we don't do that sort of splitting are two:

1. The tool that helps with packaging `clbrepo` doesn't support it, and most importantly

Maybe it is a call for looking into such support. Haskell packages are huge! There has to be a significant population of users which want a lean & mean machine. It takes about 900 MiB of installation size for haskell-conduit. Addressing this will help with adoption.

...

2. splitting into -bin and -dev packages, like in Debian/Ubuntu/..., isn't the norm in Arch

Maybe not -bin and -dev then, but something has to give. I didn't see anything against it in the packaging standards. We can liaise with the core team to find out the Arch-y way for this issue.

-- SP _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell

Le 14/04/2015 16:12, Magnus Therning a écrit :

IIRC, the regular installation doesn't support it (i.e. via Cabal). What we need is specific recipes to package tools and lib parts into separate packages, i.e. a split package.

Le 14/04/2015 23:29, Magnus Therning a écrit :

Just playing around a little with one of the packages currently in the repo comprising both a lib and a binary resulted in the attached PKGBUILD (shake). It might be close to what a solution could look like.

Thanks for having a try at this, it looks good! Have you tested it or you wish for somebody to try it out? Le 15/04/2015 02:15, Nicola Squartini a écrit :

You can pull out /usr/bin/gitit and the other files in /usr/share from the package, and upload only those to your server (once the gitit package is back).

On the other hand that sounds like and excellent idea and very simple to implement (so KISS-compliant) if the modified PKGBUILD-way proves too problematic. I'm thinking of a post-build task packaging the binary along with man pages etc.

I think it's unnecessary (and even annoying for many users) to have all packages that contains binaries split. Beside it requires modifying cblrepo. Unless the demand increases, I would suggest to simply manually split (via *.pkgbuild patches) only explicitly requested packages, like pandoc and gitit. On Wed, Apr 15, 2015 at 7:15 PM, Magnus Therning wrote:

On 15 April 2015 at 08:40, Bastien Traverse wrote:

...

Le 14/04/2015 16:12, Magnus Therning a écrit :

...

IIRC, the regular installation doesn't support it (i.e. via Cabal). What we need is specific recipes to package tools and lib parts into separate packages, i.e. a split package.

Le 14/04/2015 23:29, Magnus Therning a écrit :

...

Just playing around a little with one of the packages currently in the repo comprising both a lib and a binary resulted in the attached PKGBUILD (shake). It might be close to what a solution could look like.

Thanks for having a try at this, it looks good! Have you tested it or you wish for somebody to try it out?

I have not tested it, and there might be quite a bit of testing necessary I'm afraid.

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell

Still on the topic of reducing installation dependencies: are self-contained binaries in the style of pandoc [1] doable for gitit and other Haskell packages as well? This could be an interesting way to address the issue.

It is possible to compile pandoc such that the data files pandoc uses are embedded in the binary. (The executables in the binary are built this way.) The resulting binary can be run from any directory and is completely self-contained.

cabal update cabal install hsb2hs cabal install --flags="embed_data_files" pandoc pandoc-citeproc

[1] http://pandoc.org/installing.html#creating-a-relocatable-binary

The last time I looked at using the shared libs there were issues with rpath, basically ghc put in a search path reflecting the build dir and not the install-libdir. This was probably in the 7.6 times though. One would hope this has improved since. The Nix guys did have a solution to this, and IIRC it involved rewriting the rpath after linking.

A more or less elegant solution to the rpath problem was found in a previous thread [1]: Using GHC `-dynload=deploy' flag [3] and a `/etc/ld.so.conf.d/haskell.conf' file which specify the location of the shared libraries, e.g. `/usr/lib/ghc-7.6.3/sharedg'. Details in [2]. This solution was working well for most of the package, I remember being able to build pandoc with shared libraries, but sadly not for gtk, which has a kind of bootstrapping method that was not working with `-dynload=deploy' flag. It was with GHC 7.6, but as show in [3] the option is still present in latest GHC. Maybe it is worth another try, gtk could have changed! Not sure to have the time, but if yes I'll try it again. ++ Fabien [1] http://comments.gmane.org/gmane.comp.lang.haskell.arch-linux/1792 [2] http://permalink.gmane.org/gmane.comp.lang.haskell.arch-linux/1795 [3] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-shared...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/04/15 11:57, Fabien Dubosson wrote:

A more or less elegant solution to the rpath problem was found in a previous thread [1]: Using GHC `-dynload=deploy' flag [3] and a `/etc/ld.so.conf.d/haskell.conf' file which specify the location of the shared libraries, e.g. `/usr/lib/ghc-7.6.3/sharedg'. Details in [2].

Thanks for all this background info Fabien, it helps get this going.

This solution was working well for most of the package, I remember being able to build pandoc with shared libraries, but sadly not for gtk, which has a kind of bootstrapping method that was not working with `-dynload=deploy' flag.

One package shouldn't warp the whole package system. One should push suggestions upstream and they should be accepted if there is technical merit. In the end there is always the patch approach for rogues. - -- SP

On 15/04/15 21:44, Fabien Dubosson wrote:

I agree. As far as I remember Magnus an me were both out of time to look further into this. Maybe things have changed since. I started rebasing my past work on the last version of habs, I'll write another mail soon for a status.

Ok. I was looking for branches relating to this feature. I noticed you have one, but need to find one which has the changes proposed for cblrepo. Either way I will try to put something together, but chances are my snail pace will get beaten! Keep me posted either directly or maybe new thread? Also, been looking to see what makes things so large in the filebase. Just checking in ghc's dir, it's static libraries: ``` 185480024 /usr/lib/ghc-7.10.1/ghc_EMlWrQ42XY0BNVbSrKixqY/libHSghc-7.10.1-EMlWrQ42XY0BNVbSrKixqY_p.a 109044692 /usr/lib/ghc-7.10.1/ghc_EMlWrQ42XY0BNVbSrKixqY/libHSghc-7.10.1-EMlWrQ42XY0BNVbSrKixqY.a 76260686 /usr/lib/ghc-7.10.1/Cabal_HWT8QvVfJLn2ubvobpycJY/libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY_p.a 67111580 /usr/lib/ghc-7.10.1/site-local/highlighting-kate-0.5.14/libHShighlighting-kate-0.5.14-5S9jZ1dVOgcGI7XstIXNsq_p.a 63048936 /usr/lib/ghc-7.10.1/ghc_EMlWrQ42XY0BNVbSrKixqY/libHSghc-7.10.1-EMlWrQ42XY0BNVbSrKixqY-ghc7.10.1.so 57385398 /usr/lib/ghc-7.10.1/Cabal_HWT8QvVfJLn2ubvobpycJY/libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a 46972990 /usr/lib/ghc-7.10.1/base_I5BErHzyOm07EBNpKBEeUv/libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv_p.a 35159482 /usr/lib/ghc-7.10.1/base_I5BErHzyOm07EBNpKBEeUv/libHSbase-4.8.0.0-I5BErHzyOm07EBNpKBEeUv.a 27632384 /usr/lib/ghc-7.10.1/site-local/texmath-0.8.0.2/libHStexmath-0.8.0.2-1UuTXL14IBUBNFTO6p9bK5_p.a 25808360 /usr/lib/ghc-7.10.1/site-local/highlighting-kate-0.5.14/libHShighlighting-kate-0.5.14-5S9jZ1dVOgcGI7XstIXNsq.a ``` -- SP