[Pkg-sssd-devel] [tag2upload 3161] irrecoverable sssd 2.12.0-4

[Ian Jackson]

Hi.  I'm giving a rather long answer which I hope will be more useful
to your co-maintainers on this package, who may be lacking much
of the context.

Simon Josefsson writes ("Re: [tag2upload 3161] irrecoverable sssd 2.12.0-4"):
> However the upload still fails, see rejection output below.  I realize
> now that this is because of the patch style used for this project:
> 
> https://salsa.debian.org/sssd-team/sssd/-/blob/master/debian/README.source?ref_type=heads

This seems to describe a normal use of quilt.  I looked at the rest of
the git tree and it has the upstream files as expected.

> Could some 'git-debpush --quilt=FOO' parameter had make a difference?

Maybe it could help but I think a different fix is required.
(How did you select "uannplied" rather than "gbp"?)

I eyeballed the list of files in the report, and I think that

 1. this git branch is based purely on upstream history
 2. the orig tarball is the upstream "source" tarball
 3. the upstream "source" tarball contains many non-source objects
 4. the upstream "source" tarball omits some source files

Examples of 3 include autoconf output eg Makefile.in and the many .mo
files.  Examples of 4 include .gitignore and probably things like
contrib/test-suite, and Vagrantfile; evidently these aren't used in
the Debian package build, but they might be useful for someone working
on the Debian version of the package so they should be included.
Something is going on with src/tests/ too, that I don't understand.

In order to do a properly git-based upload, you need a git branch and
orig tarball that correspond with each other, so that the Debian
source package and formally published git history can correspond.

There are two ways to square this circle:

You can forget about the upstream orig tarball and just use upstream
git.  In a case like this that would involve choosing a new "upstream
version number" and generating a tarball from an upstream git tag.
(tag2upload can do that for you.)  My recent blog post has a few rune
suggestions for this [1].

If you did that, the new source package would be significantly
different to the previous uploads, because it would omit the
autogenerated files and include all the source files.  But the git
would remain very similar.  You might need to make some changes to the
debian/rules because (for example) the autogenerated autotools files
would now not be present.

It's also possible that you might discover that there are things your
build relies on that aren't in your git branch.  If there *are* any
such things, then they are probably autogenerated files which are you
are not regenereating from real source code; in that case the real
source code might not even be in the current source package at all!
Such things can be quite a substantial yak, but an important one:
it would be software supply chain risk and maybe a DFSG problem.

The other approach is to use gbp import-orig.  This is very common in
Debian and many people will be familiar with it.  It privileges
upstream tarball contents over upstream git, so it facilitates various
anomalies (and even attacks, see for example the famous xz attack).

If you did that, your source package would be quite like the previous
uploads.  But your Debian git branch would end up containing all this
autogenerated stuff from the orig tarball.  (You'd probably want
--quilt=gbp.)

This is the easier option.  It doesn't involve any changes to
debian/rules.  It avoids detecting uses of autogenerated files that
exist only in the upstream tarball.  (I'm reminded of the
sarcastic/parodic aphorism "never check for an error condition you
don't know how to handle.")

Hope this helps.

You can of course continue to do dput based uploads.

However, it is in cases like this that the weaknesses of "git is only
on salsa" [2] are most acute.  Because the git branch on salsa has
totally different contents to the source package, it is not really
directly useable.  The only way to use the salsa git branch to make a
source package that looks like the official source code in the ftp
archive, is to get the orig tarball from the archive and use that in
combination with the git branch from salsa.  That means that the
preferred form for modificfation of this package is the *combination*
of the git from salsa, and the orig from the ftp archive.

Of course we are all volunteers here and there are many suboptimal
things that need our attention.  And, sadly, these kind of anomaly is
quite common in Debian.  So I quite understand if opening and sorting
all these cans of worms doesn't make it to the top of your todo list.

Regards,
Ian.

[1] In the part for git-debrebase adopters, here:
  https://diziet.dreamwidth.org/20851.html#determine-upstream-git-and-stop-using-upstream-tarballs

[2] I discuss these problems in from the point of view of a user
in my 2021 blog post
  Get source to Debian packages only via dgit;
  "official" git links are beartraps
  https://diziet.dreamwidth.org/9556.html

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.