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 456532 - Systems: Profiles do not utilize package architecture
Summary: Systems: Profiles do not utilize package architecture
Alias: None
Product: Spacewalk
Classification: Community
Component: WebUI
Version: 0.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Brad Buckingham
QA Contact: Red Hat Satellite QA List
Depends On:
Blocks: space04
TreeView+ depends on / blocked
Reported: 2008-07-24 13:56 UTC by Brad Buckingham
Modified: 2010-12-16 16:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-22 16:29:43 UTC

Attachments (Terms of Use)

Description Brad Buckingham 2008-07-24 13:56:45 UTC
Description of problem:

Systems -> Stored Profile -> Packages & System -> Software -> Profile

Package profiles do not include the package architecture information. As a
result, if an i386 package is removed from an x86_64 client and the users
performs a profile comparison, they will see that the package is missing;
however, performing a sync from the profile to reinstall it on the client
results in the x86_64 package being installed. (Note: package arch information
is not received from the server during rhn_check) 

From initial analysis, impacts to schema and UI are anticipated.

How reproducible:

Steps to Reproduce:
1. select Systems
2. select an x86_64 system
3. select Software -> Packages -> Profiles
4. Create System Profile

5. remove an i386 package (e.g. libjpeg) from the client -> (Note: you might
want to install one before creating the profile above)
6. select System -> Software -> Packages -> Profile -> Compare to compare the
profile previously created to the system
7. you should see the package that was removed as a "difference" between the
profile and the system... select the package and perform "Sync Packages"
8. on the client, perform rhn_check -vvv at the appropriate time to have the
package re-installed on the client
Actual results:
- The profile that gets created (in 4) and then the comparison (in 6) do not
account for package architecture.  It is neither stored in the DB nor displayed
to the user.
- The package that is resynced to the client (in 8) will be the x86_64 version
of the package (assuming that both an i386 & x86_64 exist) vs the i386 version
that was previously installed

Expected results:
- When creating a profile, we should have the ability to store the architecture
of the packages that are associated with the system; otherwise, we are not
accurately reflecting the differences when comparing profiles.
- When performing the profile comparisons, we should display to the user details
on the architecture so that they can see if there is such a difference that exists.

Additional info: - Refer to wiki
page for more details on this issue. This page contains proposed solution;
however, since the solution details can change as the issue is further
investigated, it is not being included in the bug report.

Comment 1 Brad Buckingham 2008-12-09 16:12:46 UTC
Modifications made to system stored profiles to support arch.  This included changes such as the following:

- ported the following pages to java: 

- added package_arch_id to rhnServerProfilePackage
- profile creation (systems/details/packages/profiles/ updated to 
  populate package_arch_id
- profile comparisons (systems/details/packages/profiles/ & 
  systems/details/packages/profiles/ updated to include arch 
  in comparison and show in comparison results
- syncing (rhn/systems/details/packages/profiles/ & 
  systems/details/packages/profiles/ updated to include arch id 
  in the action that is scheduled and then picked up by rhn_check

- Systems -> Stored Profiles (profiles/ new java pg replacing list.pxt
- Systems -> Stored Profiles -> Profile (profiles/ new java pg 
  replacing details.pxt
- Systems -> Stored Profiles -> Profile -> Packages (profiles/
  new java page to replace package-list.pxt.  The new page includes listing of 
  pkg arch.
- Systems ->Stored Profiles -> Profile -> Delete Profile (profiles/ 
  new java page to replace delete.pxt

Comment 2 Brad Buckingham 2008-12-17 16:29:10 UTC
Git commits related to this bz include:


Comment 3 Brad Buckingham 2009-01-15 19:56:59 UTC
verified with spacewalk-java-0.4.14-1.el5, spacewalk-schema-0.4.15-1.el5

verified Systems->System->Software->Profiles->Create
verified Systems->StoredProfile - content looks good

verified System->Software->Profiles->Compare profile w/no diff expected
verified System->Software->Profiles->Compare profile w/ diff expected
verified System->Software->Profiles->Compare profile-> Sync Pkgs

verified System->Software->Profiles->Compare systems w/diff expected
verified System->Software->Profiles->Compare systems-> Sync Pkgs

attempting to delete the Stored Profile is generating an ISE.  This BZ will be moved to verified and a separate BZ (480233) has been created to track this failure.  Using this approach, since this BZ (456532) addressed many issues related to stored profiles.

Comment 4 ice 2010-11-22 18:38:23 UTC
It seems that the architecture information in stored profiles is only avaliable for stored profiles taken on EL5 clients or newer, but not on EL4 clients?


1. registering a el4.7 (in my case) desktop client to spacewalk and putting it into el4.7 base channel.
2. creating a stored profile (system -> software -> packages -> profiles -> create profile) like "profile basic"
3. installing some additional packages
4. creating a stored profile again like "profile additional packages"

5. synching the client to the basic profile works fine, cause the rhn_check on the client has only to remove packages.

6. But then! synching the system to "profile additional" will fail after the click on "schedule" button because the stored profile has no architecture information - so in the column "channel" there is "none". I understand it like the package e.g. "gedit.i386" is in the channel 4.7 i386, but the package "gedit" with no architecture information is in no channel, so not findable, so synch is not possible.

hope it's easy to reproduce, if not just ask me :P


Comment 5 ice 2010-12-16 16:43:06 UTC
If you have undefined architecture information in the softwre list of a rhel4.x client use the latest up2date package.

In rhel4.8 a working up2date version is already integrated (up2date-4.8.1-33.el4.i386 works fine)

Attention! If you get the spacewalk-client tools from

REMOVE!! the up2date version (up2date-4.6.2-7.el4.1.i386.rpm) from the client-tools package

It has the architecture bug not fixed and does not send the architecture information to the spacewalk platform.

And by some strage reasons, up2date-4.6.2-7.el4.1.i386.rpm is shown as update for
up2date-4.8.1-33.el4.i386 when the client is attached into spacewalk and has client-tools channel available. "Updating" to 4.6.2... will mess your architecture information again.

hope someone saves his time with that hint :P


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