I will upload a patch to support arbitrary vendor in installplatform.
Created attachment 23909 [details] A patch for vendor
There's more to this problem than just supporting an arbitrary platform vendor string. What still needs doing is to identify how to retrieve an unambiguous vendor string at install time, as, without that, there's little need for supporting the config.guess vendor string in rpm at all. Anyways I'm gonna mark this WONTFIX, but that should be taken in the sense that there's much more to do than change the installplatform script.
At the install time, VENDOR is set by VENDOR="`$RPM --eval '%{_vendor}'`" and %{_vendor} is substituted by @RPMCANONVENDOR@. In configure.in, there is RPMCANONVENDOR="$build_vendor" case "${build_vendor}" in unknown|pc|redhat|pld|mandrake|conectiva) test -f /etc/redhat-release && RPMCANONVENDOR=redhat test -f /etc/pld-release && RPMCANONVENDOR=pld test -f /etc/mandrake-release && RPMCANONVENDOR=mandrake test -f /etc/conectiva-release && RPMCANONVENDOR=conectiva ;; esac If rpm is configured with cpu-myvendor-linux, there is no problem to identify the vendor. The only problem is rpm may not be configured with the explicit vendor string. In that case, you have to guess what the vendor is. You can easily add a checking there like case x"$RPMCANONVENDOR" in xunknown|xpc|x) echo "** Unkown vendor: $RPMCANONVENDOR. Abort!" exit 1 ;; esac
Yup. I understand that, but the problem is providing a guarantee of the semantics associated with the value for %_vendor, not with permitting an arbitrary string. At the moment rpm has strong semantics for <arch> and <os> driven by uname(2) and inline asm voodoo. Similar strong semantics for vendor are gonna be needed if vendor is ever to be used reliably in rpm packaging. Otherwise, there's no reason to support vendor in rpm at all. Look carefully at what's in installplatform, the real macro configuration comes from the path /usr/lib/rpm/i386-linux not from /usr/lib/rpm/i386-redhat-linux and it's gonna take much more than permitting arbitrary vendor strings in order to complete the transition from the current arch/os based on uname(2) to a more general config.guess platform paradigm. The test for /etc/<vendor>-release on the build side is the only convention that has a prayer of mapping onto rpm installs, so I choose to deliberately limit the set of rpm vendors to those known to follow a semantic convention.