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
> 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
-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
>
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
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
> 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, 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
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 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
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
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
12 matches
Mail list logo
