|Summary:||RPM needs an Architecture: tag|
|Product:||[Retired] Red Hat Linux||Reporter:||Matthias Urlichs <smurf>|
|Component:||rpm||Assignee:||Jeff Johnson <jbj>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-09-14 18:08:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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. 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.