Hi, On 8/16/21 3:18 AM, Paul Wise wrote:
I'd like to suggest that we standardise on the upstream VCS for our orig.tar.gz files and phase out use of upstream packaging ecosystems.
This is also an additional burden on package maintainers: explaining how they arrived at that particular "upstream" package in a reproducible way, and why what we ship as "orig" is different from upstream, and what the copyright and licensing situation for that derived work is.
Upstream projects have gotten a lot sloppier in how they cut releases, that is true, and that is making packaging more difficult as we need to disable mechanisms and embedded code copies that were included for our "convenience."
Rather than accept defeat, I'd like Debian to push upstreams more aggressively for higher quality releases, and also to make judgement calls on whether a particular package is even suitable for a stable release instead of assuming that by default.
For a package to be included in Debian, it must be possible to maintain it. Working with an upstream that focuses solely on users that install through some other means is difficult in two ways, because neither our processes nor our release schedule are supported by them, so from a project management standpoint, our use case is "out of scope."
Without even minimal support from upstream, the Debian maintainer will have to do a lot of extra work. We ship a lot of packages in stable that are not supported by upstream, and every bug report to the upstream BTS will be immediately closed with "upgrade to the latest version to see if that works better", and if we want to support our users properly, the maintainers of those packages get stuck with forward-porting bug reproduction and back-porting fixes.
Part of being a maintainer is to communicate our needs to upstream, and work with them on solutions. If an entire ecosystem is dysfunctional and will not produce releases we can work with, it makes a lot more sense to me to push, as a project, for a change of the ecosystem rather than saddling individual maintainers with it.
I'd also like to see upstream tarball export systems switch to plain VCS exports plus additional tarballs for files like autotools cruft.
I think that autotools is one of the few systems that *don't* cause issues, because it encourages following proper release procedures, where the version number needs to be added to a file, all files need to be properly accounted for in the build system, out-of-tree builds need to work with all testcases passing, and the installation and uninstallation procedures need to work in order for "make distcheck" to succeed.
Encouraging upstreams to generate releases directly from VCS would likely reduce quality here.
The problematic ecosystems are those that are aimed at releasing into the ecosystem only and using the ecosystem's package manager instead of a system package manager. This is, again, not something that individual package managers can or should work around, but something we need to address at a structural level, for example by creating a policy that allows these package managers to coexist with ours in a sensible way.
This is likely to be different for different ecosystems. CPAN is rather "traditional" in its processes, many packages move slowly and upstream developers have enough insight into their packages to be able to tell whether a bug report against an older version is still valid, so (re-)packaging these is possible and provides value, while something fast-moving that is only available as a daily snapshot with no interoperability testing against different versions of dependencies might be better off in a package manager that is built for that kind of thing.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature