Re: What can Debian do to provide complex applications to its users?
Hello,
Raphael Hertzog, on ven. 16 févr. 2018 16:11:29 +0100, wrote:
> it can break in many ways whenever one the
> dozens of dependencies gets updated to some new upstream version
To me, that's really the problem: people are writing and piling layers
of free software without really caring about freeness, i.e. being able
to easily access the source code, or to seamlessly use more recent
versions of components. Hell, upstream sometimes tell me that "it's been
one year, i.e. two releases that this feature is deprecated", how can
our world work coherently with such speedy changes?
> - we could relax our requirements and have a way to document the
> limitations of those packages (wrt our usual policies)
What kind of relaxation could we introduce without damaging freeness?
The only one I can see is relaxing having to use the version of the
library shipped in Debian.
When I see upstream java packages just stuffing .jar files without
indication of where they come from or even their licencing terms, it's
just unacceptable.
> - we could ship those applications not as .deb but as container
> and let them have their own lifecycle
Well, strictly speaking Debian does not actually need to be involved
then, applications are already doing that. But it's indeed a sign that
Debian is losing relevance, which is concerning and Debian could have to
do something about it.
> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?
I am annoyed too (I use dolibarr, and am faced with that kind of
dependency hell about some a11y packages). But when I look at the
problem, the real issue is the first one I mentioned above, which not
only is a concern for Debian as you showed, but also for security,
sharing bug fixes etc. and thus the fix should ideally be there, not in
Debian.
Now, we could have separate apt repositories maintained on Debian
servers, so that at least the containers mentioned above would be using
Debian repositories with the corresponding maintenance.
Or we could try to embrace the multiple-library-versions-in-the-same-root
issue like distributions such as NixOS and Guix do. I.e. standardize
alternative places where alternative versions of libraries can be
installed (by installing package whose name contain the major/minor
version so it fits nicely into the dpkg model, and not the release
version so that upgrades are still possible), and the corresponding
environment variables be used to point those complex software at these
dependencies.
Samuel
Reply to: