Identi.ca
Apry

Apry at

@clacke, I still don't get how this first part helps with unbundling libraries from source trees that embed external stuff. If anything, on a guix system it seems more likely that you'll end up with some programs using old, perhaps problematic, versions of library dependencies than on a system where a library upgrade forces upgrade of all reverse dependecies.

WRT to mismatching implementations of protocols/formats, when you upgrade a library which does i/o of one file format to a newer version, you know there isn't a binary which might be surprised when asked to open files using new features, etc.

Functional package management solves parts of the unsatisfiable dependency hell issue but AFAIK the tradeoff is that it will keep old code around.

"Don't do that" needs to be addressed to developers, not users of a packaging system. Even for devs, that might not always be an option in practice.

Claes Wallin (韋嘉誠) shared this.

@apry@identi.ca If the system cannot handle coexisting same-major libraries, unbundling some stuff is "impossible", or rather, involves a lot of effort that may or may not be worth it. Once you have the possibility to unbundle, of course it still doesn't come for free. But you will see clearly in the tree what libs and versions are present, rather than something hiding, forgotten.

Claes Wallin (韋嘉誠) at 2015-10-24T15:32:00Z

X11R5, Christopher Allan Webber likes this.

@apry@identi.ca If formats change, the user still needs to be in the loop somehow. You may have different machines interacting, with any given version installed, regardless of what your packaging is capable of. If one package causes two other packages to communicate, that package will ensure those two packages are the right versions. Don't try too hard to solve problems that may or may not occur and may not in the end be 100% solvable through technical means.

Claes Wallin (韋嘉誠) at 2015-10-24T15:35:58Z