Comment by bmn__ | Hacker News Reader

Comment by bmn__ | Hacker News Reader

Paul Draper from TFA totally ignored the perspective of a packager.

It would be a completely unacceptable situation for application A1 to depend on DB abstraction library v0.8651, A2 on v0.8653, A3 on v0.8670, A4 on v0.87…

How do you ship this to your distro users? Almost always there is no easy way to install several libraries of the same name but different versions in parallel, and it's never supported by the distro auto-packaging tools.

Patching to use the latest version of the dependencies and verifying the patched version works ok is a huge burden on package maintainers. The application author knows the code much better!

The current solution of specifying minimum versions of dependencies exists not because we like the suffering caused by occasional breakage. No, it exists because it is a practical, working solution for the real world that is the best balanced trade-off.

The problem is that nobody really tests all the versions they specify in a dependency list. They just install the dependencies, and if everything works, commit the file.

In PHP we usually have a version range in libraries' dependencies and lock file that specifies exact dependency versions for the entire application. So you can be sure that you get tested combinantion of libraries.

I'm pretty sure lockfiles get ignored by PHP packagers as a practical matter.

Can you elaborate on what you mean? Composer is the most popular PHP packager and its two core commands - update and install - make updates to and install from the composer.lock file respectively

> The problem is that nobody really tests all the versions they specify in a dependency list

Some do. Some others target the versions shipped in a stable Linux distribution.

And even if the upstream don't test some combinations of versions, distributions will test what they ship.

> Some do.

How can they check future versions of libraries that will match the range?

> Almost always there is no easy way to install several libraries of the same name but different versions in parallel.

How is this possible is beyond my comprehension. Someone, anyone break something and I have no standard way to bypass "dll hell" (putting space problems aside)? what the actual f.

Let me unconfuse you. Look into the subdirectories of your filesystem:

    /usr/lib/perl5/vendor_perl
    /usr/lib/python*/site-packages
    /usr/lib64/ruby/gems/*/gems
    /usr/lib64/node_modules

You have only one version of each library. This is the exact opposite of DLL hell.

Reply on news.ycombinator.com