Bug 1118678 - pandoc linked to 60 shared Haskell libraries
Summary: pandoc linked to 60 shared Haskell libraries
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: pandoc
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-11 08:59 UTC by Manfred Lotz
Modified: 2014-07-15 10:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-15 05:13:54 UTC


Attachments (Terms of Use)

Description Manfred Lotz 2014-07-11 08:59:25 UTC
Version-Release number of selected component (if applicable):
pandoc-1.12.3.3-2.fc20.x86_64


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
ldd ~/.cabal/bin/pandoc
	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)
	/lib64/ld-linux-x86-64.so.2 (0x000000345f600000)




Thanks a lot, Manfred

Comment 1 Jens Petersen 2014-07-14 05:45:57 UTC
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?

Comment 2 Jens Petersen 2014-07-14 05:48:10 UTC
(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?

Comment 3 Manfred Lotz 2014-07-14 06:22:10 UTC
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.


-- 
Manfred


sudo yum install pandoc
...

=================================================================================================
 Package                          Arch          Version                     Repository      Size
=================================================================================================
Installing:
 pandoc                           x86_64        1.12.3.3-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        4.6.0.1-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        1.0.0.1-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        1.0.13.1-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        1.3.0.1-18.3.fc20           updates         43 k
 ghc-digest                       x86_64        0.0.1.2-2.fc20              fedora          11 k
 ghc-directory                    x86_64        1.2.0.1-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        1.3.0.1-18.3.fc20           updates         61 k
 ghc-hashable                     x86_64        1.1.2.5-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        2.4.1.2-31.fc20             updates        191 k
 ghc-old-locale                   x86_64        1.0.0.5-18.3.fc20           updates         49 k
 ghc-old-time                     x86_64        1.1.0.1-18.3.fc20           updates         94 k
 ghc-pandoc                       x86_64        1.12.3.3-2.fc20             updates        1.5 M
 ghc-pandoc-types                 x86_64        1.12.3.3-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        1.1.1.0-18.3.fc20           updates         57 k
 ghc-primitive                    x86_64        0.5.0.1-4.fc20              fedora          35 k
 ghc-process                      x86_64        1.1.0.2-18.3.fc20           updates         61 k
 ghc-random                       x86_64        1.0.1.1-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        2.8.0.0-18.3.fc20           updates        343 k
 ghc-temporary                    x86_64        1.1.2.4-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        1.4.0.1-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        2.6.0.1-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
 ghc-zlib

Comment 4 Jens Petersen 2014-07-15 05:13:54 UTC
Hi Manfred,

(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:

http://copr.fedoraproject.org/coprs/petersen/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. :)

Comment 5 Manfred Lotz 2014-07-15 06:17:08 UTC
Hi Jens,
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
pandoc
  Depends: libbibutils2
  Depends: libc6
  Depends: libffi6
  Depends: libgmp10
  Depends: libpcre3
  Depends: zlib1g
  Suggests: texlive-latex-recommended
  Suggests: texlive-xetex
  Suggests: texlive-luatex

which is much more convenient.

-- 
Manfred

Comment 6 Jens Petersen 2014-07-15 07:59:23 UTC
(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.

Comment 7 Manfred Lotz 2014-07-15 09:33:38 UTC
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.

-- 
Manfred

Comment 8 Jens Petersen 2014-07-15 09:42:16 UTC
(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
> of. 

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.

Comment 9 Manfred Lotz 2014-07-15 10:43:47 UTC
<  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.


-- 
Manfred


Note You need to log in before you can comment on or make changes to this bug.