Re: Potential MBF: packages failing to build twice in a row
On Tue, 08 Aug 2023 at 10:26:09 +0200, Helmut Grohne wrote:
> With this you touch another purpose of `debian/rules clean`: Removing
> generated files. Since we currently discourage repackaging and
> `dpkg-source -b` is vaguely happy about deleted files, a common
> technique for dealing with generated files is really shipping them in
> the source tree and then deleting them via `debian/rules clean` while
> relying on build tools (and our buildds do this) to clean before build.
> >From my point of view, this is the main purpose of the clean target at
> this time.
>
> Do others see this strategy of dealing with generated files as viable
> and is it compatible with git-based workflows?
It's compatible, but annoying, for a couple of reasons:
The generated files show up in the diff when looking at the changes
between two consecutive upstream releases, and need to be filtered out
or ignored based on out-of-band knowledge that actually they are going to
be deleted. This is especially annoying when they're numerous or large,
like pre-generated HTML documentation, or GLib's GResource-generated
files (which are a way to embed binary icons etc. into your executable
or library).
If you build the package with git-buildpackage or similar, there
isn't usually a need to delete them from your git working tree;
but if you build in-tree (cd mypackage, git checkout debian/latest,
debuild, debuild -T clean) or if you need to run debian/rules clean to
regenerate something that is generated-but-committed (like debian/control
from debian/control.in), then your working tree will have uncommitted
deletions which need to be committed or undone (`git checkout generated/`
or similar). If you upload with dgit, then not committing them is not an
option (because dgit requires the git tree to match the unpacked source
package 1:1), so you have to undo the deletions.
The major alternative to this use of d/clean is to repack the tarball
with the generated files completely excluded, for example via uscan with
Files-Excluded in d/copyright.
If your upstream has non-DFSG or ambiguously-licensed files in their
source releases and you need to repack a +dfsg tarball to get rid of
those files *anyway*, then there's no significant additional cost to
excluding generated and irrelevant-to-Debian files while you're there.
If not, then the decision to be made is whether the generated files are
large enough or annoying enough, in combination with other factors (like
whether there are vendored subprojects whose copyright/licensing would be
a lot of work to track in d/copyright), to justify repacking a +ds tarball
without them.
smcv
Reply to: