Re: About the recent DD retirements
Tollef Fog Heen <tfheen@err.no> writes:
> This also points at something not explicitly mentioned: Our support for
> multiple versions of the same package is pretty much non-existent. (You
> can hard-code the version into the package name. This causes NEW pain,
> this kinda breaks dependencies and doesn't map well to how at least some
> languages like Ruby handles dependencies.)
> This means that if you use system packages and want to have two
> applications that both want foo.jar installed, but different versions
> (since they need different APIs or different bug compatibility), we
> don't support that well. For C libraries, there are sonames and all,
> but those largely doesn't exist for other languages and fixing that
> would be a huge undertaking with, IMO, pretty poor prospects for
> success.
Yeah, this is a cause of serious pain. It's probably the number one
objection to using Debian packages to distribute software internally.
People don't like using a system that breaks down when different pieces of
software need different versions of some dependency, and this is very,
very common. Hence the popularity of things that fix this, such as Python
virtual_env, Java's tendency to use per-application JAR trees, Ruby's
support for doing something similar, Nix, or languages like Go that do
static compiles.
You can work around this problem by using containers for everything (or,
similar but less modern, chroots), but that introduces a bunch of new
pain.
A clean way to let, e.g., Python modules at different versions co-exist
would be really nice, but it's a very hard problem. You'd probably have
to completely redesign the way that packages are built and deployed,
similar to what Nix does.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: