On Wed, Oct 28, 2026 at 02:50:44PM +0000, [email protected] wrote: > Am 28.10.2026 13:53 schrieb Jonathan Carter (highvoltage): > > Also, if people continuously use the DFSG team as the source of > > reviewing their package copyright, > > Just a side note on that. > > Encourage and/or enforce the upstream projects to support > REUSE.software standard providing SPDX metadata. If the projects are > 100% SPDX compliant you could use the tool "spdx2debian" [2] to > auto-generate a debian/copyright file from that SPDX meta data. > > As upstream maintainer I always thought it is upstreams responsibility > to get copyright and license right and clean. DMs need to check that > of course, but they shouldn't fix it. Just my opinion. I know that the > reality is different.
Yes, thank you! This, and a lot of this!
Debian has been 25 years or more ahead of its time, by trying to solve
the problem of integration with other software rather than just
publishing one software.
It used to me that upstream published a tarball with scattered code on a
ftp site, and we had to infer and encode a lot of upstream-specific
know-how for how to build it, install it, run it, and make it play nice
with other software.
During these years, most upstream communities have at least partially
caught up, and started standardizing a lot of that. We have a lot more
expectations about how to install a PIP package, or a Rust crate, than
we used to have with a tarball a quarter of a century ago.
More than that, even if upstreams haven't yet caught up with all the
standards we could use like SPDX, there are now workflows for
contributing patches to upstream to help them catch up, or ship and
track them in Debian if they won't or until they do.
What I think we should do in Debian now is catch up with those
standards[1], phasing out Debian-specific metadata that used to be
essential but is now stopping to make sense, or can be represented
upstream.
Upstreams's main focus generally stays on publishing rather than
integration, so there's still plenty work for us to do.
I think that work shouldn't be the duplication of package descriptions
or copyright information, or basic dependencies, or everything else
which would then need to be maintained (or double checked, if you don't
think redundancy is a problem because a LLM statistically does it for
you) multiple times.
We could be tracking what upstream does, the important things in their
issue tracker, possibly be in the loop for critical security issues
reported to them, unbundling dependencies that are already in Debian so
that we don't end up with 15 copies of the eMudhra root CA certificate
embedded inside binaries in /usr, negotiate with upstreams about
backwards compatibility so that we can have a chance of offering
security support for the software for at least 2 years after stable
releases, and I'm sure at this point most of the people reading this can
come up with more things that upstreams could still do to make their
software fit Debian better but they don't yet.
Can we design for where we could go, rather than adopt an LLMs to make
it supposedly easier to stay where we are?
Enrico
[1] as Joey has already written in
https://joeyh.name/blog/entry/Debian_and_the_sirens/
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[email protected]>
signature.asc
Description: PGP signature
