[Pkg-sssd-devel] priv-wrapper?

[Timo Aaltonen]

Simon Josefsson kirjoitti 4.8.2023 klo 15.09:
> 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.

But you lose upstream git history in the process.. and looks like it's 
more steps than in 'git merge upstream; dch; (git commit;) uscan -c; 
debuild -S -d'

>> 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.

Uscan works, and d/watch is easy to modify to use upstream signatures. 
and complain if the signer is unknown.

> 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.

It's not created (at least here) without nagging that orig.tar doesn't 
exist.

This is how xorg-team packaging has worked for 15y which is where it's 
derived from, and also freeipa-team which I'm mostly responsible for :)

-- 
t