Re: Q to all candidates: what is the long-term role of traditional Linux distributions?
On 15361 March 1977, Matthew Garrett wrote:
But upstream development is increasingly diverging from our approach.
I think that depends a bit in which area you look.
Many new software ecosystems are based on external code repositories
rather than relying on the distribution, and in several languages it's
expected that a project directly include its dependencies rather than
relying on external availability.
But those software ecosystems also need a stable base that works and
allows them to ignore those mundane basics.
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 don't need every single possible bit of software packaged. That's
neither a useful nor an attainable goal.
We need as much groundwork packaged that you can use any of the existing
and new coming stuff in an easy, yet still secure, way. And that you can
do it on an otherwise stable platform. Which is something Debian does
provide pretty nicely (ok, except for releasing way too often and fast,
which is a major downside of us).
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?
It may be. As I wrote elsewhere I imagine a Debian that has a Magic
Archive (Hey, I got a free magic card there) and is *THE* answer to
everything package related, so that anyone in any language environment
(nodejs? ruby? python? perl? java? haskell? whatever) who ever goes "And
now, how do my users get the crap I wrote?" goes "OH, sure, Debian, I
just fill out this $somethingseomething and any user anywhere can
*easily* get at it, perfectly integrated in their system with all
dependencies magically resolved".
Lucky, for me, even with the magic card, I have been vague enough that
it fits even here. I do want Debian to be the platform chosen to build
other stuff upon. In whichever environment the people building are. Go,
Ruby, NodeJS, whatever. A startup that scales up tons of containers and
throws them away even faster than their humans. A big business that
thinks a new released Linux Distribution every 10 years is the best.
Someting in between that can deal with 5 years. Users at home that have
featuritis and can't wait for the next tiny dot version to finally
install.
Now, packaging it all is an effort we really can't sustain. And it
really doesn't make sense to have packages where the metadata is larger
than the code. So yes, better tooling will be part of the answer.
Our advantage, and something that we should try to keep and extend on is
our unification and consistency. Say, I want a perl module Foo::Bar, I
get it with one command and a predictable name and location and general
behaviour. Want a golang something module (just assume its packaged), I
get it with the same command and a predictable name. And so on.[1]
Are our current priorities the best way to serve the free software
community over the next 10 years?
No idea how the world will look in 10 years, but if we keep the users as
part of our priority, and adapt according to their needs, we shouldn't
be far off. And yeah, now someone asks to define users, especially with
what I wrote some lines up.
Would we be better off focusing Debian as a high-quality base for
users who then largely consume software from other sources?
I think we should not have just one focus and concentrate on that alone.
We should have multiple and continue to try to weight them against each
other as good as possible.
Footnotes:
[1] Sure, right now this requires the "needs to be packaged" part.
--
bye, Joerg
Reply to: