Okay so digging deeper into it, Nix does use absolute...

Okay so digging deeper into it, Nix does use absolute paths for libraries, but they point to the correct version of the installed library within the "Nix store". So it's not quite like Java classpaths. But this is still fine as far as avoiding version conflicts goes. It still allows you to have multiple versions of the same library installed at once.

The only place where there can be a "default" version of a package is a user/shell environment for packages that provide executables. Makes sense.

Like 13 July at 0:36 | Open on mastodon.social

3 comments

uis

Not sure about Nix, but usually versioning is done with sonames. Like libbullshit.so.1 and libbullshit.so.2, which are resolved into different versions.

And why absolute paths? This makes no sense.

13 July at 1:01 | Open on pone.social

Gregory

@uis yes, but usually those library packages would also include:
- unversioned C headers (/usr/include/bullshit)
- unversioned static version of the same library (/usr/lib/libbullshit.a)
- a bunch of symlinks (/usr/lib/libbullshit.so -> libbullshit.so.2)

So in the end, you can't have multiple versions side-by-side, so if you want to install a package that needs a newer version of this library, you also have to upgrade its dependents you installed earlier.

13 July at 1:52 | Open on mastodon.social

uis

[Part 1]

- usualy cflags for library are obtained through pkg-config, which includes headers search location, so headers can be located anywhere and be versioned. As long as config is versioned. Although usually includes(-dev packages, if talking in debianisms) are installed unversioned for "default" version
- why would you even version static libraries? They are either in binary or not.
- libbullshit.so is symlink to default version. Binaries can specify exact version.

13 July at 2:04 | Open on pone.social