On Tue, Aug 17, 2021 at 12:17 PM Simon Richter wrote: > This is also an additional burden on package maintainers: explaining how > they arrived at that particular "upstream" package in a reproducible way
Debian explaining how we arrived at a particular orig.tar.gz is well established; use a debian/watch file. It supports accessing git repositories directly. > and why what we ship as "orig" is different from upstream, and what > the copyright and licensing situation for that derived work is. I see it another way, the upstream packages/tarballs are usually a derived work of their VCS, adding cruft that should not be there and removing files that should be there. The fundamental problem is that the packages/tarballs are seen more as something for end-users (who are often developers) to run (or sometimes build) than for people building from source or for distros. So upstream packages/tarballs end up as a mix of source and binary packages. So these tarballs/packages are of a fundamentally different nature to Debian source packages and are for an entirely different audience than Debian package maintainers, who are doing the same source -> binary packaging job as upstream package ecosystems, but for the Debian packaging format instead of different formats for different ecosystems. In the case of Firefox XPI packages, they are even more like Debian binary packages, and yet Debian is using XPI packages as our source packages for webext-* packages. I agree with much of the remainder of your mail, but the world of Debian, FLOSS, software and technology in general has disillusioned me enough that I believe the efforts at improving upstream packages/tarballs/ecosystems you suggest will mostly be futile, which is why I suggest giving up on improving anything except the upstream VCS. Even that is going to be hard to improve, many upstreams will refuse to remove build system cruft, generated files, (modified) embedded code copies and so on. In both approaches, the first step is for Debian maintainers to routinely compare the upstream VCS with the chosen Debian upstream tarball. I tend to either use diffoscope or unpack and use a graphical tree diff tool like meld. Once the comparison is done, the options are to either switch to the VCS (as I suggest) or discuss the differences with upstream (as you suggest). I encourage everyone to at least think about doing the VCS comparison when adding new upstream releases to Debian and choosing one or the other path for dealing with the differences. -- bye, pabs https://wiki.debian.org/PaulWise
