-- Forwarded message --
From: Nicola Squartini
Date: Tue, Apr 14, 2015 at 9:20 AM
Subject: Re: [arch-haskell] gitit status update and why are deps needed for
binaries
To: Bastien Traverse
Solving the problem of pandoc and gitit binaries taking so much space,
would require splitt
On 14 April 2015 at 02:21, Nicola Squartini wrote:
>
> -- Forwarded message --
> From: Nicola Squartini
> Date: Tue, Apr 14, 2015 at 9:20 AM
> Subject: Re: [arch-haskell] gitit status update and why are deps needed for
> binaries
> To: Bastien Traverse
>
>
> Solving the problem o
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 th
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 tha
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
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 an
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 surpri
On Tue, Apr 14, 2015 at 03:41:26PM +0100, SP wrote:
> On 14/04/15 13:10, Magnus Therning wrote:
> > Patches are always welcome. :)
>
> Naturally. If I find time I'll give it a shot.
Just playing around a little with one of the packages currently in the
repo comprising both a lib and a binary resu
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
ment
On Tue, Apr 14, 2015 at 10:19 PM, 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
On 15 April 2015 at 00:56, Leif Warner wrote:
> 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
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 aro
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
No gitit doesn't have that flag.
Even in the case of pandoc, it will not make your installation smaller,
just embed the support files (/usr/share I guess) inside the
/usr/bin/pandoc binary.
On Wed, Apr 15, 2015 at 6:49 PM, Bastien Traverse
wrote:
> Still on the topic of reducing installation dep
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/0
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 f
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
git
On 15 April 2015 at 12:28, SP wrote:
> 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
>> li
> 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 th
On 15 April 2015 at 12:28, Nicola Squartini wrote:
> 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 patc
On 15 April 2015 at 12:57, Fabien Dubosson wrote:
>> 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 im
-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
>
> Thanks for all this background info Fabien, it helps get this going.
My pleasure!
> 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.
I
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 f
24 matches
Mail list logo
