[2018-10-04 17:41] John MacFarlane
> kact...@gnu.org writes:
>
> > We could generate packages with compressed binaries in a way,
> > similar to *-dbg packages. All compiled languages, except C (Go,
> > Rust, Haskell) would benefit, but it is quite a bit of work --
> > changes to debhelper and
Quoting kact...@gnu.org (2018-10-05 02:28:17)
>
> [2018-10-05 00:50] Jonas Smedegaard
> > Quoting John MacFarlane (2018-10-04 19:58:54)
> > > Jonas Smedegaard writes:
> > >
> > > > The proper solution here, I guess (but am not expert in Haskell
> > > > so may be wrong) is to switch to using
[2018-10-05 00:50] Jonas Smedegaard
> Quoting John MacFarlane (2018-10-04 19:58:54)
> > Jonas Smedegaard writes:
> >
> > > The proper solution here, I guess (but am not expert in Haskell so
> > > may be wrong) is to switch to using shared linking, so that 5
> > > Haskell binaries will not
Quoting John MacFarlane (2018-10-04 19:58:54)
> Jonas Smedegaard writes:
>
> > The proper solution here, I guess (but am not expert in Haskell so
> > may be wrong) is to switch to using shared linking, so that 5
> > Haskell binaries will not consume 5 x the disk space of the parts
> > reused
Jonas Smedegaard writes:
> The proper solution here, I guess (but am not expert in Haskell so may
> be wrong) is to switch to using shared linking, so that 5 Haskell
> binaries will not consume 5 x the disk space of the parts reused among
> them.
Yes, in theory. But this didn't work well in
Control: tag -1 wontfix
Hi Горбешко,
Quoting Горбешко Богдан (2018-10-04 13:02:59)
> the pandoc binary is extremely large. It's the largest file in my
> /usr/bin, exceeding even blender's binary in almost 2 times.
>
> From my experience, ghc is not good at making small binaries, and
> even
I'm happy to leave this issue up to the Debian
maintainer, since the upx compression would need to
be done in the packaging process and doesn't involve
upstream.
I tested upx compression (with --best --ultra-brute)
on macOS. Time for 'pandoc --version' went from 0.031s
without compression to
Package: pandoc
Version: 2.2.1-2
Severity: wishlist
Dear Maintainer,
the pandoc binary is extremely large. It's the largest file in my
/usr/bin, exceeding even blender's binary in almost 2 times.
From my experience, ghc is not good at making small binaries, and even
stripping doesn't do
8 matches
Mail list logo
