[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
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
Processing control commands:
> tag -1 wontfix
Bug #910280 [pandoc] pandoc: Please reduce the binary size
Added tag(s) wontfix.
--
910280: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910280
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
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
