Bug 49282 - Arbitrary vendor support in installplatform
Summary: Arbitrary vendor support in installplatform
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-17 17:26 UTC by hjl
Modified: 2007-04-18 16:34 UTC (History)
0 users

Clone Of:
Last Closed: 2001-07-17 17:27:18 UTC

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

Description hjl 2001-07-17 17:26:31 UTC
I will upload a patch to support arbitrary vendor in installplatform.

Comment 1 hjl 2001-07-17 17:27:14 UTC
Created attachment 23909 [details]
A patch for vendor

Comment 2 Jeff Johnson 2001-07-29 15:57:00 UTC
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 16:14:37 UTC
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 16:33:29 UTC
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.