[Pkg-sssd-devel] priv-wrapper?

[Simon Josefsson]

Timo Aaltonen <tjaalton at debian.org> writes:

> Timo Aaltonen kirjoitti 4.8.2023 klo 11.42:
>> Simon Josefsson kirjoitti 3.8.2023 klo 22.55:
>>> Timo Aaltonen <tjaalton at debian.org> writes:
>>>> I had a brief look at priv-wrapper packaging, and noticed it only
>>>> keeps the debian/ dir in git? The sssd-team packages have the full
>>>> upstream git as the base, with packaging added to the packaging
>>>> branch. I prefer those will remain like that :)
>>>
>>> I usually also do the full git repo with upstream branch for most of the
>>> packages I maintain, but for this new package I wanted to see if keeping
>>> only debian/ in git worked, as I've had success with that in another
>>> package.  What is really the upside of having upstream code in Debian's
>>> git?  One downside is that it wastes space, although I don't think that
>>> matters a lot these days.  Another downside is that it confuses what is
>>> really the "upstream" in case the Debian git-repo's view of what
>>> "upstream" is differs from the real upstream.
>> How do you pull a new upstream release, download the tarball? I
>> don't like working with upstream tarballs as the source of a new
>> release, git is much nicer. And it allows using snapshots when
>> needed etc.
>
> Okay, now I see that the new uid-wrapper release was imported from a
> tarball? :)

Yes, I work like this:

git clone ...
cd uid-wrapper
origtargz || uscan -dd
gbp buildpackage --git-pbuilder --git-pbuilder-options=--source-only-changes

I wish gbp buildpackage would download the tarball automatically when it
is missing, it creates them from git code automatically when that
approach is used.

> The way I've handled them is to have the upstream git as a remote,
> then pull the new release in the 'upstream' branch, with upstream
> history. That is then merged to the packaging branch.

Yeah, it is a careful balance.  The git-only approach makes it easier to
fail to download and check the PGP signature of the tarball, I think,
and as a consequence the orig.tar.gz tarball in Debian may not be
identical to the upstream tarball.

Trying to summarize...

Advantage with debian/-only:

- Save disk space and bandwidth when checking out the git clone.

- Forces Debian developer to use origtargz/uscan to download pristine
  release artifacts, and (with debian/upstream/signing-key.asc) verify
  the PGP signature, to avoid that being mistakenly omitted.

- No risk of confusion between what constitute genuine upstream code and
  what is Debian's version of upstream's code.

Advantage with debian/ inside full source code:

- Easier pure git-based workflow against upstream git repository.

Disadvantage with debian/-only:

- Preparing snapshot releases of unreleased upstream code is harder.

Disadvantage with debian/ inside full source code:

- Easy to forget to download release tarball artifact and verify PGP
  signature, since the orig.tar.gz is generated from git automatically,
  and the release PGP signature *.asc file is not stored in git, so will
  not end up in the Debian archive.

There is the pristine-tar approach to at least get pristine tarballs,
but it doesn't support storing the *.asc as far as I know.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-sssd-devel/attachments/20230804/3dc6bc61/attachment.sig>