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