Hacker News Reader

Comment by nn3 | Hacker News Reader

pandoc is one of the few packages (among with tetex) i black listed on my distribution for automatic updates because it seems to pull in hundreds of other packages which are not used by anything else.

I don't know how they did it, but somehow they put dependency hell on a completely new level.

Yes i'm sure it's a great tool, but there's a limit how much bloat I can tolerate for a single program.

View on HN

That's your distro's problem.

    $ zypper info --requires pandoc

    libm.so.6()(64bit)
    libpthread.so.0()(64bit)
    libm.so.6(GLIBC_2.2.5)(64bit)
    libpthread.so.0(GLIBC_2.2.5)(64bit)
    libm.so.6(GLIBC_2.29)(64bit)
    libdl.so.2()(64bit)
    libdl.so.2(GLIBC_2.2.5)(64bit)
    libz.so.1()(64bit)
    libc.so.6(GLIBC_2.17)(64bit)
    ld-linux-x86-64.so.2()(64bit)
    ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
    libgmp.so.10()(64bit)
    libpthread.so.0(GLIBC_2.3.2)(64bit)
    libm.so.6(GLIBC_2.27)(64bit)
    librt.so.1()(64bit)
    libutil.so.1()(64bit)
    libpthread.so.0(GLIBC_2.12)(64bit)
    libnuma.so.1()(64bit)
    libnuma.so.1(libnuma_1.1)(64bit)
    libnuma.so.1(libnuma_1.2)(64bit)
    libffi.so.8()(64bit)
    libffi.so.8(LIBFFI_BASE_8.0)(64bit)
    libffi.so.8(LIBFFI_CLOSURE_8.0)(64bit)

    $ rpm -ql pandoc | grep -v '^/usr/share'

    /usr/bin/pandoc

    $ ll -h /usr/bin/pandoc

    -rwxr-xr-x 1 root root 162M Sep 30 13:33 /usr/bin/pandoc

That would seem that your distro is statically linking all the Haskell libraries. On distros that use dynamic linking for everything, it's also going to pull in (directly or indirectly) ~130 Haskell libraries.

Correct.

This has little do with pandoc and everything with how awfully Haskell packages are packaged for some distros. Imagine if installing a program that runs on node would pull in every single npm dependency as its own package.

That's the point though: you should only need one package manager.

> That's the point though: you should only need one package manager.

That's orthogonal to the issue. Even with just one package manager, how packages are created and maintained is a separate task.

So, if the pandoc package has dependencies vendored, dependency hell is avoided regardless of which package manager is used to install it.

If, however, the pandoc package has all dependencies listed as separate packages, dependency hell is created, again regardless of which package manager is used to install it.

So this is a matter of policy, not tooling.

I think the difference is in the visibility of dependency hell, not the existence of it.

Can I wager a guess that you are on Arch?

The Arch (and some other linux maintainers) have made the decision to package all Haskell libraries as separate OS packages and install those as dependencies when you install, say, pandoc. This model of distribution doesn't really make much sense for distributing Haskell binaries, though.

There's a few reasons for this: 1) since most people don't have many Haskell binaries and the few that people use don't share many libraries, 2) Haskell packages are normally statically linked when building executables.

If linux maintainers would simply build/ship pandoc as a single static executable all these issues disappear.

Nice!

I'm on Arch, but I was under the impression that Debian did the same thing for Node/Haskell modules. Or am I mistaken?

Does that actually matter? To me dependency hell is when you have lots of conflicts where some software requires one version but some other software needs a different version. So you can't upgrade one version without breaking something else.

With pandoc and all the haskell dependencies, the only downside is the length of the list of packages when you upgrade. If it was all bundled up as haskell-all I doubt I'd even notice.

That's probably because it's compiled dynamically in your distro's package manager. If you look for a statically compiled option, it might be more to your taste.

And there are statically-compiled versions available for multiple platforms on Pandoc's download page. (I tend to use those for the Mac, rather than installing through Homebrew.)

Arch, I presume? That's mostly due to a man-power problem on the side of the Arch Haskell maintainers. Try our pandoc Docker images or use pandoc-bin from AUR for a bloat-less version. https://hub.docker.com/u/pandoc

Considering what pandoc does and how it is used, docker is a massive overkill imho. What pandoc should actually do, is come as a tar ball and be buildable the traditional configure make make install way like all unix tools of a similar fashion do. Haskell, atm, is no language for this.

Hahaha, that's actually some quality and funny trolling. Not bad :D

For everybody interested in alternative installation methods: all pandoc releases are available as statically compiled binaries for Linux, and via installers on macOS and Windows. Any major package managers ship a more-or-less recent version of pandoc. Compiling is as simple as getting the "stack" tool and running `stack install`.

If you’re concerned, run it in docker and dispose the container after you’ve got your output docs

Reply on news.ycombinator.com