When people hear I'm from Debian, this is the second most common question I get. The first is about systemd and gives me a great opportunity to talk about how Debian works and about how we're a community facing tough challenges together. Here's the answer I give on this issue for Debian of today. Debian is great at giving you all the parts of what you need to do that aren't your primary focus. Even if you're a Python developer, you're going to want some not Python stuff. Even if you install everything you can out of pip, some day you'll run across a dependency that's not really a Python dependency. (My classic example of ruby-sass has gotten more complex because of libsass and its python bindings, but the point is still very much true). The free software ecosystem crosses language boundaries. And Debian provides you with a great consistent interface for approaching a lot of the common dependencies that are outside your core focus. Yet Debian also supports the tools for other repositories when you choose that. And that's a great answer as far as it goes. I truly believe it; I have lived it regularly and will continue doing so. However, I think this is an area where someone spending some real time developing a Debian vision and helping us move in that direction can help. I think packaging free software even from languages that have their own system is valuable in a lot of ways. First, we have a way of expressing dependencies that cross language boundaries well. We have a consistent approach to validating licensing that seems better than a number of other repositories in terms of respecting the DFSG and/or more generally the four freedoms. Especially for big packages, what we do is valuable. I've run with the upstream packaging of gitlab, and I know I'm looking forward to using our packaging. Our consistency, our approach to stability and security updates really are valuable to a lot of users. I know I want a docker.io in Debian. Our wordpress packaging has saved me a lot of effort. Yeah, you get stuck with something old, but if that works for you, I've found that our packaging is a lot easier to leave stable than the upstream. The upstream forces upgrades at times that are not convenient for me and forces me into situations where I have to spend effort I don't have. The Debian packaging still requires security updates, but I have more confidence they can be applied without breaking things or changing other behavior. And yet people are spending a lot of time curating modules from languages that have their own repositories. Yes, I'm sure this work has value. I think we should do a better job of letting people know that we recognize the value and articulating to ourselves and our users what that value is. However, it's a lot of effort, and we should understand we'll never package all that is out there. We should encourage people spending this effort to evaluate whether it is the best use of their time. More than that, I think we need to find a better way to interact with these technologies. For example I'm disappointed that flatpak is constructed in such a way that you can't use debian packages to help satisfy application dependencies even if you are using a deb-based flatpak runtime. (The debs would install into /usr which is reserved entirely for the runtime). I think that having a container system that would allow people to use debs both on the runtime and application side could significantly leverage our repository in those environments. You might well still want to build the primary app from upstream sources with no packaging, but I think we should try to find a role in both the runtime side of things as well as the dependencies that are not included in the runtime that a given app needs. (I'm aware of the technical issues to what I propose and am sure there are lots of politics too) I think we should also look at how we can interact better with these other package managers. I doubt we want packages in Debian main that depend on random ruby gems or go packages pulled from an external repository. However perhaps we want that to be possible for third parties. Where it's not already possible perhaps we want to work with language specific repositories to express dependencies that don't come from their language in distribution terms. Several of the language-specific installers are already good at allowing system modules of the appropriate version to satisfy dependencies. In general, I think this is an area where we need some focus. And it's with a fair bit of regret that I realize I probably cannot provide that focus in my first term as DPL if elected. I think that the emphasis on communication and decision making I plan to focus on will give us necessary skills as a project to approach this sort of work. I think that focusing on removing some of our internal workflow challenges will help us make changes. But realistically I think there's only so much one person can do in one year. I think this is important--critically important even in in a long enough horizon--and yet beyond where I think I can personally spend my energy right now. It sucks; I think that the emotional, political and technical aspects of this are interesting and challenging. And yet I look at what I wrote in my platform and what I've talked about already, and I don't want to change my priorities. I would be eager to find some way to help empower others to work on this. I don't have an explicit plan in that area and note I've already talked about a lot of ways I'd work with people and there's a lot of already existing teams and finite time. --Sam
Attachment:
signature.asc
Description: PGP signature