On Mon, 2021-08-23 at 17:07:13 -0700, Vagrant Cascadian wrote:
> On 2021-08-23, Guillem Jover wrote:
> > On Fri, 2021-03-19 at 11:32:52 -0700, Vagrant Cascadian wrote:
> >> Note that it is only a partial patch; it doesn't export DEB_BUILD_PATH
> >> in dpkg-buildpackage and/or dpkg-buildflags; help as to the best place
> >> to implement that would be appreciated!
> >
> > The ideal place to export such variable would be from
> > dpkg-buildpackage, but sadly as long as that's not the canonical entry
> > point for building packages, I'm seeing only doing that if the
> > implementation can avoid assuming the variable is set and shows no
> > regressions in that case.
>
> I noticed SOURCE_DATE_EPOCH was defined in:
>
> /usr/share/dpkg/pkg-info.mk:SOURCE_DATE_EPOCH ?= $(call
> dpkg_late_eval,SOURCE_DATE_EPOCH,dpkg-parsechangelog -STimestamp)
>
> Would it make sense to do the same for DEB_BUILD_PATH? Or would CURDIR
> not be the right value at that time? Are there cases where
> SOURCE_DATE_EPOCH isn't defined when building packages (e.g. fakeroot
> debian/rules build). From a reproducible builds perspective, it seems
> SOURCE_DATE_EPOCH is working well enough, and defining DEB_BUILD_PATH in
> the same place should be good enough too.
The difference being that a missing SOURCE_DATE_EPOCH causes at most
"just" an unreproducible build. While a missing DEB_BUILD_PATH
currently (AFAICS) would break the build. :/ See below.
> >> From 2f2985a12673866a341551399a5461fe8d7e617b Mon Sep 17 00:00:00 2001
> >> From: Vagrant Cascadian <vagr...@reproducible-builds.org>
> >> Date: Sun, 14 Mar 2021 00:19:56 -0800
> >> Subject: [PATCH] Implement reproducible=(fixfilepath|fixdebugpath) as spec
> >> files.
> >
> >> diff --git a/data/fixdebugpath.specs b/data/fixdebugpath.specs
> >> new file mode 100644
> >> index 000000000..e1cc16b0a
> >> --- /dev/null
> >> +++ b/data/fixdebugpath.specs
> >> @@ -0,0 +1,2 @@
> >> +*self_spec:
> >> ++ -fdebug-prefix-map=%:getenv(DEB_BUILD_PATH =.)
> >
> > I'm not sure the equal sign is correct here?
>
> I'm not sure what's wrong with it ...
>
> Currently fixdebugpath would set something like:
>
> -fdebug-prefix-map=/absolute/path/to/build/dir=.
>
> This gets the value of DEB_BUILD_PATH from an environment variable
> instead.
>
> Or is there something I'm not grasping with how .spec files work?
Ah, misread the function documentation, and I see now that it just
gets appended to the value from the envvar, and is not a fallback
value. Sorry! Although now that I reread this carefully I see that
it's perhaps worse than I thought, as there's this part:
'getenv'
The 'getenv' spec function takes two arguments: an environment
variable name and a string. If the environment variable is
not defined, a fatal error is issued.
That would mean that if the environment variable is not defined, we
fail the build. :(
> […] as long as you set the DEB_BUILD_PATH environment variable
> only once per build... it should effectively be a fixed value.
But that's a problem, because unfortunately debian/rules is still a
supported package building entry point, when using that directly there
is no guarantee that DEB_BUILD_PATH would be set. Which would make the
build fail.
> When I tested this, I added in debian/rules:
>
> export DEB_BUILD_PATH=$(CURDIR)
>
> And everything *seemed* to work correctly.
Sure, but that's the thing we cannot guarantee to be happening. :)
So, one option would be to make dpkg-buildflags try to look for the
debian/ directory to try to determine the source tree root dir.
Unfortunately I don't think that'd be reliable, as I could imagine
there being calls from subdirs containing debian/ hierarchies and
similar, even though that might be contrived, but dpkg-buildflags has
never required being called from within a Debian source tree.
(If only we could finally just make dpkg-buildpackage the only
supported entry point…)
Thanks,
Guillem
