On Sat, 17 Feb 2018, Russ Allbery wrote: > The reason why Debian in general doesn't like to support vendored source > is because of the security implications: when there's a security > vulnerability in one of the vendored libraries, updating the relevant > packages becomes a nightmare. It's a logistical challenge even if the > vendored source can be safely upgraded, but of course it usually can't > since that's the whole point of vendoring the source. So we would be > faced with backporting security fixes to every vendored version of the > package, and we don't have the resources to do this.
We might not have the resources to do this but we should have the infrastructure to track those problems, make them available to upstream, and get them to fix their vendored libraries. And let users decide whether it's safe to install or not, and track the security status over time. I don't agree that "vendored sources" cannot be safely upgraded. It really depends on the reason why the source has been vendored. When it's a deliberate fork, then yes the upgrade might be hard. But more often than not, it's just a convenience to avoid system dependencies or a simple way to ensure that the project has the version that they expect. Furthermore many projects have continuous integration tools that let them know whether things are still working after the update (be it because they switched to latest upstream of all their dependencies, or because they upgraded a library that they had vendored). > It's hard to avoid the feeling that we have two choices with these sorts > of applications: I think Debian has never been afraid of tackling hard problems and we should find a third way. I don't want to lower the quality of what we have built so far, so while it's technically possible to build .deb and include a bundle of libraries pinned at the correct version, I don't think that this should allowed into the main archive. However I also think that Debian has to provide all those hard-to-package applications to end users. Right now, my gut feeling is that the best approach is probably to rely on containers built out of Debian binary packages for the plumbing and with the language-specific package management tool for the application libraries. The role of the Debian developer is then to maintain a recipe file that is used to build the container (and future updated versions) and to provide some integration with the host to export/import data out of the application (think backup/restore). Since Debian would start to provide many containers like those, we would likely also start to build infrastructure to manage those containers, including some way to identify security vulnerabilities present in the container and a lintian for containers. And we would draft a policy for how to manage an application in a container, etc. Our core value is here and we can still provide value to our users in the new world that is emerging around us. We should just stop to be afraid of it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
