On Sun 2024-05-19 20:43:58 +0200, Guido Günther wrote: > But you'd break that when filtering out files? I think what keeps me > confused: the tarball uploaded to Debian is the filtered one and hence > has a different checksum, no?
hm, i don't think so, because we use
import-orig.filter-pristine-tar=False. This lets me preserve both the
upstream signature and the git history, and to compare the upstream
tarball with the git tag using git as well. In the gnupg2 package, we
currently have this in debian/gbp.conf:
---------
[DEFAULT]
debian-branch = debian/unstable
upstream-branch = upstream-2.2
pristine-tar = True
upstream-vcs-tag = gnupg-%(version)s
[import-orig]
filter = [
'aclocal.m4',
'build-aux/compile',
'build-aux/config.rpath',
'build-aux/depcomp',
'build-aux/install-sh',
'build-aux/missing',
'build-aux/mkinstalldirs',
'build-aux/texinfo.tex',
'ChangeLog',
'config.h.in',
'configure',
'doc/gnupg.info*',
'doc/*.pdf',
'doc/*.png',
'INSTALL',
'm4/iconv.m4',
'm4/intdiv0.m4',
'm4/intl.m4',
'm4/lock.m4',
'm4/printf-posix.m4',
'm4/size_max.m4',
'm4/uintmax_t.m4',
'm4/wint_t.m4',
'*/*/Makefile.in',
'*/Makefile.in',
'Makefile.in',
'po/*.gmo',
'po/Makefile.in.in',
'po/stamp-po',
'regexp/_unicode_mapping.c',
'regexp/UnicodeData.txt',
'common/audit-events.h',
'common/status-codes.h',
'ChangeLog-2011',
'*/ChangeLog-2011',
'tests/*/ChangeLog-2011',
]
filter-pristine-tar = False
---------
So what i'm asking is to be able replace that big import-orig.filter
array with something that knows how we do cleaning, so that when i
improve our cleaning, it improves the filter for the next import as
well.
> It would also have the upside that packages invoking `dh_clean … path1
> path2` would still work.
>
> Another reason to not parse debian/clean verbatim is that we'd also need
> to support dh's substitution variables and would forever need to follow
> what dh does (and we might even need to pay attention to the dh compat
> level of the package) as otherwise things would break on people.
you've convinced me that running the clean target is better than trying
to parse debian/clean :)
>> whether the packaging used debhelper or not. Does that seem like a
>> plausible way to operate gbp import-orig?
>
> That would be an approach. Implementation wise the "tricky" bit is
> that you don't have debian/ on the upstream branch you want to filter so
> dh_clean or `debian/rules clean` won't work as is . So we'd need to
> overlay that (which is certainly doable, just wanted to point it out).
ah, yes, i see the complication here.
> So that's a lot of effort for s.th. that can already be done via either
> gbp.conf or FilesExcluded. I'm not against it, just looking at the pros
> and cons.
right, i see tradeoff you're describing, and if you decide this is too
much complication for gbp, i'm willing to just keep the two lists
(debian/clean and debian/gbp.conf's import-orig.filter) in sync more or
less manually.
But i thought it wouldn't hurt to ask -- it'd certainly be nice for
anyone working on the GnuPG packaging (or any other packaging which
covers a similar upstream) to have a simpler packaging maintenance
workflow.
Thanks for thinking this all through with me here, Guido!
--dkg
signature.asc
Description: PGP signature
