Red Hat Bugzilla – Bug 499667
i386 child channels of an x86_64 base, cannot be compared with similar child channels whose base is a different arch
Last modified: 2010-11-02 15:23:44 EDT
This bug is being opened to track separately the issue raised by https://bugzilla.redhat.com/show_bug.cgi?id=438298#c1. Below is the text from that comment.
Ok, I 'fixed' the reported issue by recreating the subchannels with the x86_64
architecture, now auto subscription and management via webGUI works again as it
should. However, as these channels are originally cloned from i386 or noarch
channels, no package compare can be done any more with their 'cloned from'
channels, as these are of a different architecture.
Once again, our channel structure:
- RCH packages RHEL5 master i386
- RCH packages RHEL5 master noarch
- RCH packages RHEL5 master x86_64
RCH stating RHEL5 AP x86_64 (clone of original RHEL 5 x86_64)
- ... (clones of original RHEL 5 subchannels)
- RCH staging RHEL5 AP x86_64 RCH-Pkg i386 (clone of RCH packages RHEL5
- RCH staging RHEL5 AP x86_64 RCH-Pkg noarch (clone of RCH packages RHEL5
- RCH staging RHEL5 AP x86_64 RCH-Pkg x86_64 (clone of RCH packages RHEL5
Now, when going to Channels -> Manage Software Channels ->
RCH staging RHEL5 AP x86_64 RCH-Pkg noarch -> Packages -> Compare Packages
the 'cloned from' channel is not selectable in the dropdown box when
selecting which channel to compare with, because the 'cloned from' channel
is base architecture IA-32 and the cloned channel is base architecture x86_64.
But making the cloned channel base architecture IA-32 as well, systems can not
subscribe to it...
The solution we require:
Both channels (cloned from and clone) must of the same base architecture,
so comparison works fine
- what base architecture should noarch channels be?
- systems must be able to subscribe to such channels even if the system is
of a different architecture!
- adding/removing these channels through the webGUI must be possible!
We keep the cloned channels the same base architecture as their parent
channel, no matter what the base architecture of the 'cloned from' channel
- package comparison, errata cloning etc. must be possible!
I do guess the second suggestion is easier to do.
Description of problem:
We need to evaluate the above comment and define/implement a solution.
Version-Release number of selected component (if applicable):
The original bug (bug 438298) this was included in was for Satellite 5.0.1; however, issue also exists in Satellite 5.3.0.
Steps to Reproduce:
1. satellite-sync x86_64 & i386 rhel 5 base and child channels
2. clone the rhel5 x86_64 base channel
3. clone a rhel5 i386 child channel, making it a child of the x86_64 base channel cloned in 2
4. attempt to compare the cloned child channel to the original child channel
(i.e. Channels -> Manage Software Channels -> Channel -> Packages -> Compare)
5. observe that the original i386 child channel from 1 is not available as an option to be selected. The user appears to only be presented with those channels whose base channel is x86_64.
So drop down menu should not restrict the display for comparision (of a child channel) to other channels who's base channel arch matches, but allow you to compare a child channel with other channels and child channels who's arch matches that of the child itself (not of its associated parent).
Code is currently perl. I will approve a review to resolve this bug, on assumption it is not too complex and likely to break/cause regressions within 5.3 (otherwise punt off 5.3 release and tackle as a migration to java early in 5.4 cycles).
So, two possible solutions:
1 - allow comparision of any channel to those matching the same arch of the channel (ignore base channel arch associations)
2 - allow comparision of any channel to *any* channel, ignore arch all together.
Implemented option 2 from comment #1.
Verified on staged (Satellite-5.3.0-RHEL5-re20090724.0) with updates from Aug 20, 2009
Verified channel packages compare behaviour described by option 2 in comment #1
moving to RELEASE_PENDING
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.