[Rpm-maint] [rpm-software-management/rpm] Add support for generating buildinfo file as subpackage (#1532)

Panu Matilainen notifications at github.com
Thu Sep 1 06:08:02 UTC 2022


@pmatilai commented on this pull request.



> +# in this Software without prior written authorization of the copyright holder.
+#
+
+set -e -o pipefail
+
+getos() {
+    # shellcheck disable=SC1091
+    test -r /etc/os-release && . /etc/os-release
+    if test -z "${ID}"; then
+        ID="$(cat /etc/system-release)"
+    fi
+    printf '%s' "${ID}"
+}
+
+RPM_BUILD_ROOT="$1"
+RPM_BUILD_DIR="$2"

Rpm checks against embedded BUILDROOT in the packages already and fails the build when found, we should probably extend that to cover BUILD DIR because references to that are equally a bug, always. Had to look up the redhat-rpm-config change - Doxygen needs a whack in the head, really. I also believe it has options to disable that, if not then we should file a bug on it.

Yeah the "security" aspect is lame, and source + debuginfo packages having them is one thing, it's just that for a moment I thought we're talking about the main binary packages ... but we're not, this is supposed to go into a subpackage. Which I'm not sure makes a whole lot of sense in the first place: you have to fish the plaintext file from inside an rpm. It'd be different if the relevant data could be queried in an rpm header itself, but we don't want to add two dozen new tags specific for just this either. Is there a rationale for this particular design somewhere? (it should be in the commit messages of this thing!)

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

Message ID: <rpm-software-management/rpm/pull/1532/review/1092814814 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220831/3c1a0f2c/attachment.html>


More information about the Rpm-maint mailing list