[pkg-gnupg-maint] salsa repositories layout

[Daniel Kahn Gillmor]

Thanks to Christoph and Andreas for the discussion here!

Andreas's explanations match my own intuitions and understanding of the
situation -- i'm probably the one the most responsible for the state of
the repo leading up to Christoph's stepping up to the plate here.

Christoph, the changes you've look pretty reasonable to me.  thanks for
paying attention to that detail and trying to retain the repo structure!

Looking at the libgpg-error repo on salsa, i noticed that the
debian/experimental branch's packaging metadata (in d/control and
d/gbp.conf) still referred to the debian/master branch.  I've just
pushed an update on the debian/experimental branch so that future
uploads on experimental will reference the right branch.  If/when we
eventually merge the branch back into debian/master, we can of course
revert that specific change.

One other thing i'd recommend is to try to cryptographically sign the
git tags that are created by gbp development.  it looks to me like the
debian/1.42-1 tag in libgpg-error is currently unsigned.

On Wed 2021-05-19 14:04:39 +0200, Christoph Biedl wrote:
> About the filtering, to throw in another opinion: I prefer to deviate
> from upstream as little as possible, in general not at all. Even if
> there are files that don't make sense at all in the Debian build
> ecosystem. Notable exceptions are license issues, huge files that are
> not really necessary, and files that disturb the build process - an in
> such cases I'd rather repack the upstream tarball then.

I definitely agree with you that we want to minimize divergence from
upstream -- the challenge here is that there are several conflicting
goals:

 a) we want to track upstream's git repository -- this makes it easier
    to grab changes from upstream, and to propose debian-specific
    changes that upstream might accept, because we're working from
    closely-linked git histories.

 b) upstream ships signed tarballs, and debian wants to track those
    tarballs (and their cryptographic signatures), but the upstream
    tarballs themselves diverge from the upstream git repo (generated
    files, line numbers injected in the po/*.po, changelogs, etc)

 c) as a debian developer, i'd like to be able to recreate the entire
    upstream source tarball *and* debian packaging from the git
    repository.  pristine-tar helps us to do that.

 d) when generated files are committed to the upstream git repo (*and*
    when they shipped in the tarball -- sometimes both!), debian often
    regenerates those files anyway, because the standard debian build
    process wants to make sure that we're using free software tooling
    for the complete build.

    for example, imagine if upstream were to use some proprietary fork
    of autoconf, which generates "special" files in build/*.m4.  (i
    can't imagine GnuPG upstream doing this, but the principle holdes
    for all upstreams) If those generated files aren't actual source --
    that is, if they aren't the preferred form of modification -- and if
    debian can't generate them directly, then we can't actually build
    the package from source.  In just one example, this is why dh has
    enabled dh_autoreconf as of compat level 12 by default.  Same goes
    for re-generating documentation files from source, diagrams, etc.

    But, if debian is re-generating all the generated files during the
    build, and debian's tooling changes them subtly, then the build will
    end up modifying files that are "upstream" without recording those
    changes in debian/patches/ -- those modifications will linger in a
    gbp repo as unaccounted changes.  We don't plan to use those files
    anyway, so it's simpler and easier (and cleaner to review) if we
    filter them out of the repo during gbp import-orig.

So accomodating all of that is a bit messy, but the current structure of
the various GnuPG repos is the closest i've been able to come to account
for all of it.  If you've got any specific suggestion for how to change
the workflow that meets these goals (and/or improves on them, of
course!) i'm all ears, there's always more to learn.

Many thanks again for your work on GnuPG in debian, Christoph.  It's
really good to see.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20210525/3d412f2a/attachment.sig>