Bug 535382 (RHQ-2084) - missing the "none" architecture
Summary: missing the "none" architecture
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: RHQ-2084
Product: RHQ Project
Classification: Other
Component: Database
Version: unspecified
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact:
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks: RHQ-2083 rhq_triage
TreeView+ depends on / blocked
 
Reported: 2009-05-12 23:25 UTC by John Mazzitelli
Modified: 2023-09-14 01:18 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-05-06 20:31:22 UTC
Embargoed:


Attachments (Terms of Use)

Description John Mazzitelli 2009-05-12 23:25:00 UTC
need to add to the dbsetup/dbupgrade scripts a new row in the RHQ_ARCHITECTURE table - the "none" architecture.

Comment 1 John Mazzitelli 2009-05-13 06:44:57 UTC
Rather than add a new arch, if arch is "none" we should consider manually switching it to be our standard "noarch". We hardcode "noarch" in a few places in the code when we are talking about a arch-independent package. So we might want to just replace "none" with noarch before querying/inserting in RHQ_ARCHITECTURE.


Comment 2 Corey Welton 2009-08-14 19:49:27 UTC
I don't think handling this as a noarch (see sub-bug) is the correct thing to do -- noarch means something specific, i.e., a package that is arch-agnostic. A return of "(none"), however is indicative that the rpm provides nothing for the arch value.  I think if we were to file  rpms that return an arch as "(none)" from the rpm output as noarch, it might cause other issues down the road. 

A possible solution down the road might be to dynamically generate all arch types that exist on a system, rather than store a static list of them in the RHQ_ARCHITECTURE table. Something like

`rpm -qa --queryformat "%{ARCH}\n"|sort|uniq`

...would return a list of all arches that exist on any given system.  We could then store these in a db record for each inventoried system. Alternately, we could continually populate RHQ_ARCHITECTURE  with this data as more arches are discovered. This would keep us from necessarily having to update the table with one-offs any time a new arch is discovered, and would keep us from throwing errors if something unexpected comes our way.



Comment 3 Red Hat Bugzilla 2009-11-10 20:57:26 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2084


Comment 4 wes hayutin 2010-02-16 16:57:49 UTC
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 5 wes hayutin 2010-02-16 17:02:43 UTC
making sure we're not missing any bugs in rhq_triage

Comment 6 Corey Welton 2010-08-25 15:54:49 UTC
Charles, this one's on you per prioritization of platform plugin-related issues.

Comment 7 Red Hat Bugzilla 2023-09-14 01:18:41 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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