Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
On Tue, 19 Jan 2021 at 05:02:29 +0100, Guillem Jover wrote:
> On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> > SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the
> > algorithm for use is similar: if it is in the environment then use it, if not,
> > fall back to the previous behaviour.
>
> Yes! And as this was triggered by reproducible builds, and as you
> mention due to the similarities, it would nice to publish a “spec”
> once we reach some agreement, given that would end up being part of
> a neutral project, with more chances for upstream adoption.
One problem that I can see with SOURCE_BASE_DIR (compared with, for
example, what GLib does) is: what is "the package"? Many codebases
get used both as an independent package in their own right, and as a
bundled/vendored subproject in larger projects. Even if *in Debian* we
don't like vendoring projects that have their own independent releases,
*outside Debian* people do this all the time. There is explicit support
for this in at least Autotools and Meson, and it's used both for
vendoring subprojects that are released independently and for dealing
with subprojects that are logically separate but never actually released
separately.
For instance, in Debian we think of gcc-10 as a single, monolithic
source package, but it's really made up of three upstream tarballs (gcc,
gm2 and newlib) containing 35 Autotools build systems (estimated by
counting files named configure.ac). Obviously it isn't reasonable to
expect dpkg or debhelper to know that they should somehow set a different
SOURCE_BASE_DIR when recursing into the content of each upstream tarball,
or when recursing into each of those 35 Autotools build systems.
Similarly, we think of gnome-shell as a single monolithic package, but
as of 3.38.3 it consists of a top-level Meson project with 4 subprojects
(that do not have any independent existence as source releases, although
I think at least one of them is a non-API-stable "copylib" that exists
in more than one GNOME package).
We also think of GTK as a single package, but when built in non-Debian
contexts, it supports building external dependencies like GLib and Cairo
as subprojects instead of using a system copy. In Debian, by policy we
don't do this, but people who are building GTK apps for Windows absolutely
do want to take this approach, and GTK upstream needs to support both.
In the case of a vendorable dependency like GLib, this means that when
you're building GLib, SOURCE_BASE_DIR might be set to the top of GLib
(when building it as a package in its own right), or it might be set to
the top of GTK (in which GLib is a subprojects/glib subdirectory). The
thing I would always want to know, as a GLib developer who wants to load
a resource into my unit test, is the top of GLib.
GLib's G_TEST_SRCDIR/G_TEST_BUILDDIR sidestep this by being defined in
terms of the current directory, rather than some top-level package. This
means it isn't really feasible for dpkg to implement them - they have
to be something that the upstream build system provides, because
it's the upstream build system that does the recursion. Constructs
like Autotools' $(top_srcdir), $(abs_builddir), etc. and Meson's
meson.project_source_root(), meson.current_build_dir() etc. are very
suitable for implementing things like G_TEST_SRCDIR/G_TEST_BUILDDIR,
and they are defined in ways that make sense for that upstream build
system, taking into account how it deals with subprojects.
smcv
Reply to: