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