Re: What can Debian do to provide complex applications to its users?
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/
Reply to: