Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
Hi,
I'm not a candidate but the topic resonates with me and I want to share my
thoughts also because I am in the position to do or fund some work related
to all this.
In Kali, we have software that are close to impossible to package because
they have plenty of dependencies and sometimes even require specific
(non-current) versions of said dependencies. For ruby applications, we
tend to package them crudely by embedding a "bundle" of all the
dependencies but that's not very nice. Some applications are also poorly
coded and we want to avoid side-effects on the system or other
applications due to bad behaviour of some application executed as root.
Our current idea is to try to deliver such applications in containers
that would be installed in the (host) Kali system and managed from there
as well.
On Tue, 02 Apr 2019, Matthew Garrett wrote:
> Given these upstream shifts, is attempting to package as much software
> as possible something that actually benefits Debian and our users, or is
> it something that brings us a duplication of effort?
We definitely add value when we package something. But we should embrace
the change in the ways to deliver software... when it's not possible to
package something cleanly, we should still make it possible for us to
deliver said software to the user, e.g. as a containerized application (but
maybe others have better ideas of how to deliver hard to package
applications).
Instead of maintaining the source package, we will maintain the rules to
build the container from the real packages (for the base system) and from
the upstream sources (for the application) and from third-party
language-specific package managers (for dependencies).
Exactly like we did for packages, we would build an ecosystem around those
containerized applications including policies, common rules, linters, etc.
A containerized application would still be integrated on the host system
(e.g. the application would show up in the menus, etc.) and we would
provide the glue required to upgrade those apps over time (e.g. dump the data
from the old container, import them into the new container).
> If we spent time on
> building tooling to automatically identify that (say) installed Go
> applications that contain dependencies with security vulnerabilities and
> alert users, would that be time better spent than independendly
> packaging and maintaining those dependencies ourselves?
Packaging and maintaining the dependencies has value. But it's not always
possible to use those packaged versions and in that case, it would be nice
if we could let users know of the vulnerabilities that they are exposed to
by using some outdated software in their containerized applications. We
have most of the data in the security tracker already. It would require
some supplementary work but it's clearly something achievable.
> Are our current priorities the best way to serve the free software
> community over the next 10 years? Would we be better off focusing Debian
> as a high-quality base for users who then largely consume software from
> other sources?
I'm not sure that we have "priorities". But we have grown around the
central role of package maintainers and that's what most contributors are
currently familiar with. And I'm not sure that we have to trade being a
good base against maintaining many packages, we should be able to do both.
But I would definitely love to make Debian the base used by all upstreams
when they decide to ship their application as a flatpak or as a snap. And
they would do so because we have all the building blocks readily
available, nice tooling to make this easy, good documentation to help
them, etc.
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: