Red Hat Bugzilla – Bug 536304
Add package metadata to indicate if it supports multiple architectures
Last modified: 2008-08-27 16:44:00 EDT
In addition to versionless content, there seem to be a growing number of package types that do not care about architecture. While we have an enumerated value for this (noarch), it would be useful to express the architecture-less nature of a package type, giving us the ability to limit the amount of things requested in the UI. I'm envisioning something like a property "supportsMultipleArchitectures" that is defined as part of the package type.
Related to this is actually using this concept, specifically in the package-backed resource create to not show the architecture drop down and default to "noarch".
I'm not sure I like "supportsMultipleArchitectures" if I'm simply defaulting to "noarch" if this is false. Two options:
- I suppose it might be more flexible to have the metadata be "singleArchitecture" and have its value be set to "noarch". This would allow package types that do have architecture to only be of a specified type.
- Change the property to be something akin to "supportsArchitecture", meaning whether or not architecture is even relevant to the package type. This makes defaulting to noarch make more sense.
- Added metadata to a package type to indicate if there is the concept of architectures. Updated DB schema and parser to read and persist this information. Added check in package-backed resource creation to not render the architecture drop down when architecture is not supported (defaults to "noarch" internally in this case).
Note that this can easily be tested with RHQ-666.
This change affects the database and thus should be tested as both a clean installation as well as an upgrade.
- If the server successfully starts without throwing any exceptions preventing any plugins from loading, the DB is correct.
- To verify the DB structure explicitly, make sure the table rhq_package_type has a column of type "boolean", named "supports_architecture", and is set to "not null". In postgres, I checked this by using psql to connect to the database ("psql rhq") and typing "\d rhq_package_type". In Oracle, I used the web interface and navigated to the table's description.
- Navigate to create a new EAR or WAR file.
- On the screen where the package name and file inputs are displayed, the page should *not* show a drop down for architecture.
- Complete the EAR or WAR deployment and make sure it works correctly.
QA Verified -
supports_architecture | boolean | not null
Furthermore, after submitting ear/war files they deploy correctly.
I tried this on an upgrade install, and the ear creation fails. Joseph is going to open a separate bug for this.
I did verify the postgres tables on the upgrade install, rev1250. Have not tried oracle, I don't even have an oracle instance.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-669
This bug relates to RHQ-763