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: Always 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: https://fedorahosted.org/spacewalk/wiki/MultiArchEnhancements - 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.
Modifications made to system stored profiles to support arch. This included changes such as the following: - ported the following pages to java: /network/profiles/list.pxt /network/profiles/details.pxt /network/profiles/package-list.pxt /network/profiles/delete.pxt - added package_arch_id to rhnServerProfilePackage - profile creation (systems/details/packages/profiles/Create.do) updated to populate package_arch_id - profile comparisons (systems/details/packages/profiles/CompareProfiles.do & systems/details/packages/profiles/CompareSystems.do) updated to include arch in comparison and show in comparison results - syncing (rhn/systems/details/packages/profiles/SyncSystems.do & systems/details/packages/profiles/SyncProfiles.do) updated to include arch id in the action that is scheduled and then picked up by rhn_check - Systems -> Stored Profiles (profiles/List.do) new java pg replacing list.pxt - Systems -> Stored Profiles -> Profile (profiles/Details.do) new java pg replacing details.pxt - Systems -> Stored Profiles -> Profile -> Packages (profiles/PackageList.do) new java page to replace package-list.pxt. The new page includes listing of pkg arch. - Systems ->Stored Profiles -> Profile -> Delete Profile (profiles/Delete.do) new java page to replace delete.pxt
Git commits related to this bz include: 36e376667111909d47e5b8a1dbc7891d47f79442 949a5f3304b141fae8c948c90b86e33cb2a5f223 171e3ed99c68b5fe996128b34f5e1948f3ba4a32 6d64814fa80c6def11bf3633cc8e6451b3949fac
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.
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? reproduction: 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 cheerio
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 http://stahnma.fedorapeople.org/spacewalk-tools/4/i386/ 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 cheerio