Re: Potential MBF: packages failing to build twice in a row
On Sat, Aug 05, 2023 at 05:29:34PM +0100, Simon McVittie wrote:
>...
> One way to streamline dealing with these generated files would be
> to normalize repacking of upstream source releases to exclude them,
> and make it easier to have source packages that genuinely only contain
> what we consider to be source.
What do we actually consider to be source?
Debian maintainers with proper git workflows are already exporting all
their changes from git to debian/patches/ as one file - currently the
preferred form of modification of a Debian package has to be in salsa
and not in our archive when the changes cannot be represented as quilt
patches against tarballs.
> At the moment, devref §6.8.8.2 strongly
> discourages repacking tarballs to exclude DFSG-but-unnecessary files
> (including generated files, as well as source/build files only needed on
> Windows or macOS or whatever[1]), and Lintian strongly encourages adding
> a +dfsg or +ds suffix to any repacked tarball, which makes it less
> straightforward to track upstream's versioning. Is it time for us to
> reconsider those recommendations?
>
> For many upstreams (for example Autotools-based projects, and any project
> like GTK that includes pre-generated documentation in source releases),
> we can get "more source-like" upstream source releases by repacking our
> own tarball based on upstream VCS tags than we would get by using their
> official source release artifacts. For other upstreams, Files-Excluded
> can be used to delete generated or unneeded files.
>...
The proper solution would be to stop pretending that we are still living
in the last millenium and that tarballs would be the main form of sources.
Not using git trees as sources for many packages is preventing a lot of
proper and easy tooling for many things, including here.
> smcv
>...
cu
Adrian
Reply to: