@keszybz commented on this pull request.


> +
+printf 'Installed-Build-Depends:\n' >> "$BUILDINFO"
+rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}\n' \
+    | LC_ALL=C sort -t: -k2 \
+    | sed -e 's/^(none)://; /\.(none)$/d; s/^/ /' >> "$BUILDINFO"
+
+printf 'Environment:\n' >> "$BUILDINFO"
+
+# Whitelist from Debian's Dpkg:
+# 
https://anonscm.debian.org/git/dpkg/dpkg.git/tree/scripts/Dpkg/Build/Info.pm#n50
+ENV_WHITELIST=
+
+# Toolchain.
+ENV_WHITELIST="$ENV_WHITELIST CC CPP CXX OBJC OBJCXX PC FC M2C AS LD AR RANLIB 
MAKE AWK LEX YACC"
+# Toolchain flags.
+ENV_WHITELIST="$ENV_WHITELIST CFLAGS CPPFLAGS CXXFLAGS OBJCFLAGS OBJCXXFLAGS 
GCJFLAGS FFLAGS LDFLAGS ARFLAGS MAKEFLAGS"

The environment in various stages of the build depends on various packages in 
the build environment, so I don't think we should try to capture it. It shoud 
be reproduced when the same packages are installed. But it seems that `rpm` 
passes the environment passed in from the outside into the build environment, 
so capturing that seems useful. `/proc/self/environ` sounds like a reasonable 
option.

OTOH, if the builds are done in `mock`, the environment would be sanitized 
anyway. `mock` now uses `systemd-nspawn`, and it standarizes the environment to 
a large degree. Nevertheless, it does inject some information, like 
`container_host_*`. This was added in 
https://github.com/systemd/systemd/pull/15891/commits/e1bb4b0d1dd91ea13792e9d16d4bbf4ab8385f58.
 I wonder if we should add a switch to systemd-nspawn to opt out of setting 
those variables and make mock use it. The environment inside of mock should not 
care at all about the host.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1532#discussion_r1032988061
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/1532/review/1195037...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to