[Pkg-utopia-maintainers] stretch-pu: package flatpak, maybe want debdiff against security?

[Simon McVittie]

On Sun, 16 Jul 2017 at 10:24:36 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff against security?"):
> > gtk-doc.make is copied in from gtk-doc-tools by gtkdocize during the
> > upstream autogen.sh run. It isn't currently replaced by dh_autoreconf.
> > I could re-run gtkdocize with Debian's gtk-doc-tools at dh_autoreconf
> > time if the release team want, but my assumption had been that this
> > non-minimal change would be rejected.
> 
> It seems to me that this means that the source code for your proposed
> updated package is not entirely within Debian.  That is, your source
> code includes the source in gtk-doc-tools which produces gtk-doc.make.

The source code for gtk-doc.make is itself. The canonical copy is in
gtk-doc (Debian package gtk-doc-tools) and is copied into packages that
consume it by gtkdocize, but it isn't compiled or machine-edited: the
version in gtk-doc is no more or less the preferred form for editing
than the version in flatpak_*.orig.tar.xz.

Before you object on the grounds of embedded code copies, gtk-doc.make
is a convenience copy specifically intended to be used in this way
(Policy §4.13). If it wasn't intended to be used in this way, then the
Autotools integration recommended by the gtk-doc maintainers (a large
part of which *is* gtk-doc.make) wouldn't arrange for gtk-doc.make to
be copied into distributed tarballs.

> But the
> relevant gtk-doc-tools is not in Debian, because it's the one upstream
> used to prepare their flatpak "source" package.
> 
> So this is, technically, a violation of the licence and of policy.

If this is something you feel strongly about, I would suggest that bugs
filed against either release.debian.org or individual Autotools packages
like Flatpak are not a suitable place to arrive at a solution; and there
seems to be consensus that Autotools "make dist" tarballs are something
we want to use as our source code.

If we want to treat upstream's tarball releases as privileged and use them
wherever possible (Devref §6.7.8.1) then upstreams will have a limited
supply of patience and goodwill if we start to insist on those tarball
releases being prepared in a specific way or on a specific distribution. I
think we should avoid expending that goodwill unnecessarily, particularly
if we want upstreams to pay attention when we ask them to remove non-Free
files. Flatpak upstream uses Autotools and gtk-doc according to their
documentation on some arbitrary non-Debian distribution (I think Alex
uses Fedora, and in practice he makes all the releases).

For anything built with Autotools, if we want "orig" tarballs to contain
exactly those files that upstream prefers to modify (all files in the
upstream VCS and no files not in the upstream VCS) then we cannot obey
Devref §6.7.8.1 in its current form. We have to pick one, and obeying
Devref is the common practice.

codesearch.debian.net says Flatpak is one of around 3234 source packages
using something resembling Automake's "make dist" (search terms:
"path:configure M4sh\ Initialization"). If it is preferable to recommend
some derivative of git-archive output (in Flatpak's case it would have
to be a submodule-aware variation of git-archive) then that is a rather
extensive change, and one that contradicts what we have traditionally
asked our upstreams to do. A number of upstreams that produce tarballs
specifically because Debian has asked them to would likely be rather
upset to be told that their tarballs are in fact unacceptable to Debian,
so this is not something I am willing to do without clear project
consensus, and in particular not something I am going to mess with in
a stable-update.

> > Yes. Blame Autotools.
> 
> I think that's unfair on autotools...

It is primarily Autotools from which we get this convention that upstream
source releases contain additional files beyond what was written by the
upstream of this particular package (in this case Flatpak). gtk-doc.make
is, if anything, more source-like than aclocal.m4, which we seem to be
willing to tolerate in thousands of packages (aclocal.m4 is not source
in the strictest possible sense, but it is a trivial concatenation of
files that are source).

    S