[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

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
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

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

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.


Attachment: signature.asc
Description: PGP signature

Reply to: