On 2021-08-24, Guillem Jover wrote: > 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. ... > 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. :(
Got it. So in order to use this we would need to ensure any used environment variable is *always* set... >> […] 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…) I see. Ok, a slightly more complicated workflow pseudocode: if DEB_BUILD_PATH && fixfilepath then -spec=/usr/share/dpkg/fixfilepath.spec ... else if fixfilepath -ffile-prefix-map= build_path ... fi In other words, only pass the spec file that requires DEB_BUILD_PATH to be set when DEB_BUILD_PATH *is* set, falling back to the previous behavior setting ffile-prefix-map directly? Another pseudocode idea: if fixfilepath then setenv DEB_BUILD_PATH $build_path export DEB_BUILD_PATH -spec=/usr/share/dpkg/fixfilepath.spec fi live well, vagrant
signature.asc
Description: PGP signature
