Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 6436 - RPM needs an Architecture: tag
Summary: RPM needs an Architecture: tag
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 6.1
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-28 00:58 UTC by Matthias Urlichs
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-09-14 18:08:26 UTC


Attachments (Terms of Use)

Description Matthias Urlichs 1999-10-28 00:58:48 UTC
Let's say my installed package contains both
architecture-specific and nonspecific components. For
instance, the SNMP library (code, and MIB files).

I'd like to be able to say
Name: libsnmp

...

%package mibs
Summary: MIB files for libsnmp
Architecture: noarch

thus the code would get i386 or whatever, and the
libsnmp-mibs package would be created with "noarch".

Currently I see no way to do that, other than splitting the
whole thing into two separate packages which happen to share
a source file (libsnmp.tar.gz or whatever), which isn't
really a good idea IMHO.

Comment 1 Jeff Johnson 1999-10-28 15:07:59 UTC
This feature comes up from time to time on rpm-list@redhat.com. Here's
the current rationale for not providing the feature:

The lack of the ability to have a noarch sub-package is a conscious
design decision in rpm. The intent has been that the arch/os platform
is unchanged throughout the processing of a spec file on a build
system in order to provide a stronger guarantee that the binary
packages are associated with a single source package generated on a
single build host at a certain moment in time.

Permitting a sub-package with "BuildArch: noarch" weakens this
guarantee because there would be a set of generated noarch packages,
one from each of the build platforms, all with the same name, some of
which may not "work" (consider packaging something like X11 fonts in a
noarch package that might have byte-order dependencies in older
formats) dependent on which build host was used to produce the noarch
package.

Comment 2 Jeff Johnson 2001-02-21 19:37:33 UTC
Gonna close this, as I can't change the behavior.


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