Shrinkwrap: Taming Dynamic Shared Objects | Hacker News Reader

Shrinkwrap: Taming Dynamic Shared Objects

fzakaria.com

20 pointssmasher1643 comments

> Changing the needed dynamic dependencies to point to absolute paths, especially when those paths are immutable and content-addressable, may have philosophical and legal considerations for certain open-source licenses such as LGPL.

> LGPL specifically mentions that only in the case of dynamic linking is the license not propagated over. Although these dependencies go through the process of being dynamically linked, the library they are linked to is effectively fixed.

If I understand, after running Shrinkwrap, only the pathname of the library is changed in the resulting binary. This is easy to reverse by removing the directory parts of all pathnames altogether (I can imagine an unshrinkwrap utility that does that) or by some interactive tool that can do that on a per-entry basis.

Since detecting shrinkwrapped binaries is easy and so is inverting the process, I assume there is no violation of LGPL intent here. If anything, I can imagine that a user that wants to change the version of the dynamic library in question can take an existing Guix/Nix recipe, run the hypothetical unshrinkwrap/reshrinkwrap on its binaries, and therefore create a new Nix/Guix package with a new hash that new software packages can then depend upon. Still sounds LGPLish in nature - just with much stricter binary versioning, which is a technological requirement and not a legal one.

Shrinkwrap is a tool that attempts to overcome some of the performance limitations with how software may be packed in store-like models by freezing the dependencies directly on the executable.

Hm. So it binds like static linking, but with the dynamic linking space overhead that you pull in the entire library even if you only need some of it?

One of the arguments for dynamic linking is that you get upgraded for free when new shared objects are provided. Does this break that?

Yes, as far as I understand it breaks it, but combined with a package manager like Nix / Guix / Spack, this tool enables atomically upgrading dynamic library dependencies on a per-package basis rather than globally. If you want all applications to use a new version of a shared library, you'd need to re-"dynamic link" all of the reverse dependencies with this tool, but those package managers can handle that for automatically, and without needing access to the object files (unlike true static linking).

As I see it, that pattern is more of an alternative to container images, where this still gives you atomic dependency updates for an application without resorting to shipping N copies of each dynamic library.

Reply on news.ycombinator.com