On 2023-08-09 10:56 +0100, Simon McVittie wrote: > 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? > > > 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. I generally prefer to do this. The original source is smaller (often dramatically so: today's example shinks from 18MB to 2.3MB after excluding some test images of uncertain provenance). I find a lot of upstream sources shrink by a factor of at least 3 if you get rid of the cruft. I'm not sure why we discourage this as it does seem pointless to fill up our archive with vendored copies we don't use/want or windows binaries, docs that will be rebuilt anyway, or similar. For stuff that is sufficiently extraneous I don't always put a +ds in either, as what's left really is the source, not 'the source plus a load of pointless cruft for other OSes'. I understand why we like to distinguish between 'upstream exactly' and 'a modified version', but there is a common set of repackings which really is just a better version of 'actually the source'. I think it's good practice to use these as our 'upsteam', and I'm not convinced of the value of adding a '+' suffix in this case. Perhaps we could/should adjust policy to say that this is in fact good practice? > 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. Agreed. > 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. There is very little work in adding some exclusions to debian/copyright. That's it, and then (at least for uscan/uupdate/debuild/sbuild type workflows) everything 'just works'. So it's easy to justify in terms of maintenance effort IMHO. The only maintenance load comes if/when upstream move things around. I have never tried Helmut's suggestion of removing this stuff in the clean target. It does seem to me that removing it from the tarball makes a lot more sense than cleaning it later. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature