Re: Debian choice of upstream tarballs for packaging
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
Reply to: