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/
