Bug 49282 - Arbitrary vendor support in installplatform
Arbitrary vendor support in installplatform
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-07-17 13:26 EDT by hjl
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-17 13:27:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A patch for vendor (575 bytes, patch)
2001-07-17 13:27 EDT, hjl
no flags Details | Diff

  None (edit)
Description hjl 2001-07-17 13:26:31 EDT
I will upload a patch to support arbitrary vendor in installplatform.
Comment 1 hjl 2001-07-17 13:27:14 EDT
Created attachment 23909 [details]
A patch for vendor
Comment 2 Jeff Johnson 2001-07-29 11:57:00 EDT
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
Comment 3 hjl 2001-07-29 12:14:37 EDT
At the install time, VENDOR is set by

VENDOR="`$RPM --eval '%{_vendor}'`"

and %{_vendor} is substituted by
@RPMCANONVENDOR@. In configure.in,
there is

case "${build_vendor}" in
        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

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

  echo "** Unkown vendor: $RPMCANONVENDOR. Abort!"
  exit 1
Comment 4 Jeff Johnson 2001-07-29 12:33:29 EDT
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
not from
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.

Note You need to log in before you can comment on or make changes to this bug.