Version-Release number of selected component (if applicable):
When installing pandoc I'm forced to install the Haskell compiler suite which doesn't make sense to me as the pandoc package provides just a command line tool.
For those wanting to do development in Haskell regarding pandoc they may install
ghc-pandoc.x86_64 : Haskell pandoc library
ghc-pandoc-devel.x86_64 : Haskell pandoc library development files
ghc-pandoc-types.x86_64 : Types for representing a structured document
ghc-pandoc-types-devel.x86_64 : Haskell pandoc-types library development files
I would be happy if those superfluous dependencies could be removed as the Haskell compiler suite is only needed for building pandoc but not for running pandoc if the pandoc executable was build the (IMHO) correct way.
When I build a pandoc standalone executable then I have
linux-vdso.so.1 => (0x00007fff09592000)
libz.so.1 => /lib64/libz.so.1 (0x0000003460a00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003461a00000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003474600000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003a8dc00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003460200000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x0000003475600000)
libffi.so.6 => /lib64/libffi.so.6 (0x0000003462a00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003460600000)
libc.so.6 => /lib64/libc.so.6 (0x000000345fa00000)
Thanks a lot, Manfred
Sorry I don't understand.
Could you please post the explicit yum command and output.
pandoc does not require ghc itself to install.
Maybe you are complaining about the shared Haskell libraries...
in which case what what are you trying to do exactly?
(In reply to Jens Petersen from comment #1)
> Maybe you are complaining about the shared Haskell libraries...
> in which case what what are you trying to do exactly?
Reading again - I guess this is indeed what you don't like.
Why do you preferred a Haskell statically linked binary?
As a normal user I want to install just pandoc. I don't want to install the whole ghc compiler suite just because I want to use pandoc.
The following is annoying. I just want to install a single package pandoc. That is why I'm asking for a statically linked pandoc executable.
sudo yum install pandoc
Package Arch Version Repository Size
pandoc x86_64 220.127.116.11-2.fc20 updates 259 k
Installing for dependencies:
compat-lua-libs x86_64 5.1.5-1.fc20 updates 158 k
ghc-HTTP x86_64 4000.2.8-32.fc20 updates 172 k
ghc-aeson x86_64 0.6.2.1-2.fc20 updates 207 k
ghc-array x86_64 0.4.0.1-18.3.fc20 updates 131 k
ghc-attoparsec x86_64 0.10.4.0-2.fc20 fedora 200 k
ghc-base x86_64 18.104.22.168-18.3.fc20 updates 1.7 M
ghc-base-unicode-symbols x86_64 0.2.2.4-4.fc20 fedora 10 k
ghc-base64-bytestring x86_64 22.214.171.124-3.fc20 fedora 23 k
ghc-binary x86_64 0.5.1.1-18.3.fc20 updates 101 k
ghc-blaze-builder x86_64 0.3.1.1-2.fc20 fedora 42 k
ghc-blaze-html x86_64 0.6.1.1-2.fc20 fedora 294 k
ghc-blaze-markup x86_64 0.5.1.5-3.fc20 fedora 47 k
ghc-bytestring x86_64 0.10.0.2-18.3.fc20 updates 205 k
ghc-conduit x86_64 126.96.36.199-1.fc20 updates 103 k
ghc-containers x86_64 0.5.0.0-18.3.fc20 updates 334 k
ghc-data-default x86_64 0.5.1-3.fc20 fedora 12 k
ghc-deepseq x86_64 188.8.131.52-18.3.fc20 updates 43 k
ghc-digest x86_64 0.0.1.2-2.fc20 fedora 11 k
ghc-directory x86_64 184.108.40.206-18.3.fc20 updates 60 k
ghc-dlist x86_64 0.5-11.fc20 fedora 12 k
ghc-extensible-exceptions x86_64 0.1.1.4-13.fc20 fedora 7.1 k
ghc-filepath x86_64 220.127.116.11-18.3.fc20 updates 61 k
ghc-hashable x86_64 18.104.22.168-4.fc20 fedora 20 k
ghc-highlighting-kate x86_64 0.5.6-1.fc20 updates 2.7 M
ghc-hslua x86_64 0.3.10-2.fc20 updates 52 k
ghc-lifted-base x86_64 0.2.2.1-1.fc20 updates 24 k
ghc-mmorph x86_64 1.0.0-2.fc20 fedora 11 k
ghc-monad-control x86_64 0.3.2.1-2.fc20 fedora 21 k
ghc-mtl x86_64 2.1.2-27.fc20 updates 33 k
ghc-network x86_64 22.214.171.124-31.fc20 updates 191 k
ghc-old-locale x86_64 126.96.36.199-18.3.fc20 updates 49 k
ghc-old-time x86_64 188.8.131.52-18.3.fc20 updates 94 k
ghc-pandoc x86_64 184.108.40.206-2.fc20 updates 1.5 M
ghc-pandoc-types x86_64 220.127.116.11-1.fc20 updates 346 k
ghc-parsec x86_64 3.1.3-30.fc20 updates 105 k
ghc-pcre-light x86_64 0.4-13.fc20 fedora 24 k
ghc-pretty x86_64 18.104.22.168-18.3.fc20 updates 57 k
ghc-primitive x86_64 0.5.0.1-4.fc20 fedora 35 k
ghc-process x86_64 22.214.171.124-18.3.fc20 updates 61 k
ghc-random x86_64 126.96.36.199-26.fc20 fedora 64 k
ghc-resourcet x86_64 0.4.10.2-1.fc20 updates 43 k
ghc-scientific x86_64 0.2.0.2-1.fc20 updates 51 k
ghc-semigroups x86_64 0.8.5-3.fc20 fedora 82 k
ghc-syb x86_64 0.4.0-35.fc20 updates 39 k
ghc-tagsoup x86_64 0.13.1-1.fc20 updates 334 k
ghc-template-haskell x86_64 188.8.131.52-18.3.fc20 updates 343 k
ghc-temporary x86_64 184.108.40.206-4.fc20 fedora 14 k
ghc-texmath x86_64 0.6.6.1-1.fc20 updates 178 k
ghc-text x86_64 0.11.3.1-2.fc20 fedora 378 k
ghc-time x86_64 220.127.116.11-18.3.fc20 updates 209 k
ghc-transformers x86_64 0.3.0.0-33.fc20 updates 99 k
ghc-transformers-base x86_64 0.4.1-9.fc20 fedora 10 k
ghc-unix x86_64 18.104.22.168-18.3.fc20 updates 170 k
ghc-unordered-containers x86_64 0.2.3.0-3.fc20 fedora 64 k
ghc-utf8-string x86_64 0.3.7-8.fc20 fedora 43 k
ghc-vector x86_64 0.10.0.1-7.fc20 fedora 401 k
ghc-void x86_64 0.5.11-3.fc20 fedora 15 k
ghc-xml x86_64 1.3.13-2.fc20 fedora 72 k
ghc-yaml x86_64 0.8.8.2-1.fc20 updates 110 k
ghc-zip-archive x86_64 0.1.3.4-3.fc20 fedora 47 k
(In reply to Manfred Lotz from comment #3)
> As a normal user I want to install just pandoc. I don't want to install the
> whole ghc compiler suite just because I want to use pandoc.
You're not install all of ghc just some of the libraries
that pandoc requires to run. For quite a while we have
been using dynamic linking for Haskell packages in Fedora.
It is less portable but saves space and bandwidth,
and is consistent with Fedora's general use of shared library.
> The following is annoying. I just want to install a single package pandoc.
> That is why I'm asking for a statically linked pandoc executable.
For portability reasons I have made a copr repo with
a Haskell statically linked pandoc:
so if you really prefer you can use it though it won't
save you much time or space since you just get a fat
static executable instead.
If you take your argument to extreme then all
executables in Fedora should be purely statically linked.
I don't think this is desirable or a good idea. :)
Ok, you are right. It isn't the compiler suite but the Haskell runtime libs.
< You're not install all of ghc just some of the libraries
< that pandoc requires to run.
You say 'some'. I have to install 60 ghc library package which is more than just some.
It is interesting to see how ubuntu handles this:
apt-cache depends pandoc
which is much more convenient.
(In reply to Manfred Lotz from comment #5)
> Ok, you are right. It isn't the compiler suite but the Haskell runtime libs.
> < You're not install all of ghc just some of the libraries
> < that pandoc requires to run.
> You say 'some'. I have to install 60 ghc library package which is more than
> just some.
Okay, granted 60 is not a small number of dependencies I concede.
For reference we have about ~280 Haskell packages now in Fedora,
of which nearly 30 provide executables. For example they are
all linked to ghc-base, which means if they were static there
would be 30 copies of (parts of) libHSbase.a in Fedora.
In fact there are even some optional dependencies of pandoc
that we don't have yet in Fedora that would increase the number
even further (eg http-conduit).
It is kind of a fact of life that modern modular programming
languages tend to have many small coupled libraries.
Actually there was some discussion about static linking on
Fedora Haskell list a while back and there general consensus seemed
to be that it would be a bad idea to move back to static linking.
I should maybe ask the Debian/Ubuntu Haskell people why
they still stick with static - I guess for portability
and ease of installing as you mentioned.
> It is interesting to see how ubuntu handles this:
> which is much more convenient.
Right Debian and Ubuntu still use static linking of Haskell libraries.
There is even one drawback of those many dynamic libraries. If for instance a newer version of library ghc-lx would require a rebuilt of pandoc or any other Haskell written program then all those dependencies must be taken care of.
From what I observed things like this happened (and perhaps still happen) in Haskell eco system. Think about the cabal 'dependency hell' which at least I observed in the past in complex situations when building snap, yesod, pandoc and other larger programs.
(In reply to Manfred Lotz from comment #7)
> There is even one drawback of those many dynamic libraries. If for instance
> a newer version of library ghc-lx would require a rebuilt of pandoc or any
> other Haskell written program then all those dependencies must be taken care
Right - that is why we include the ghc ABI hashes in the package metadata
in Fedora Haskell to explicitly ensure we have consistency in dependencies.
It is true that it is a burden, but using static linking only really
hides the problem: if the libraries have changed then the executable
should really be rebuilt. That is kind of the whole point of shared
libraries but of course the situation is a bit extreme with ghc
where all reverse depends have to be rebuilt anyway.
< if the libraries have changed then the executable
< should really be rebuilt.
I don't agree here. If the executable's source code has been changed then it must be rebuilt.
If a library has been changed then we have basically two situations:
1, it is a bugfix, and the developer of the executable needs the fix. Then s(he) will release a minor upgrade to her executable by just recompiling.
2. enhancements to a library could lead to a situation where the devloper of the executable wants to benefit from. Probably even a source code change might be necessary. Then he also will release an upgrade to his executable.
Both situations require a rebuild of the rpm package.
Conclusion: Rebuilding is something the developer of the software decides upon. Only then the package builder follows by rebuilding the package.