Hi,
I've been using Debian and Debian derived distributions for quite some
time, and understand enough of how packages work to get by day to day
But as new packaging formats like snap/flatpack and approaches like
immutable distros have been receiving more attention recently,
questions about the design decisions behind the apt/deb package system
have been occurring to me, and I'm really just not sure where to ask
them. If there's a better forum, please let me know.
My main profession is as a Java developer, and the philosophy behind
the packaging/repository systems(gradle/maven etc..) is essentially to
store software in something in a hirearchy like
${group}/${app}/${version}/, and it's therefore possible to have
different versions of the same package installed side by side, and
referenced by various downstream packages which can refer to their
dependencies by including a listing of their 'dependency coordinates'.
(Debian) Linux by contrast always has an idea of 'the' installed
version of a package, also a complicated directory tree that packages
could install themselves into in various ways, as well as complicated
pre and post triggers. But like java packages, they also contain [a
more flexible] idea of what their own dependencies are.
Now, my question is why is it that one would not be able to adopt some
system convention allowing various versions of the same package to be
installed side by side, and therefore avoid a lot of the 'dependency
hell' situations that users sometimes get themselves into? It seems to
me like a much more natural evolution of application packaging than the
current container driven trends.
Are there a lot of technical complications with respect to how the
traditional file hierarchy would have to change? Is there some concern
about somehow exchanging 'install time' issues for 'run time' issues?
Is it because the mechanics of how packages are written/installed are
unconducive to these types of changes? Are there complication relating
to how pre/post triggers are written? Is it a matter of not attempting
to fix 'what ain't broke'?
Or is there a more philosophical objection about how a cohesive
software system should be designed, and how best to achieve a measure
of compatibility/compactness across a broad range of packages?
Thanks,
Masoud
