Bug 49282

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.