Bug 139562 - (IT#54400) search results for ia64 packages offers i386 packages for download.
search results for ia64 packages offers i386 packages for download.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Web Site (Show other bugs)
RHN Stable
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike McCune
Vlady Zlatkin
:
Depends On: 154743 162536
Blocks: 147875
  Show dependency treegraph
 
Reported: 2004-11-16 13:21 EST by Steve Conklin
Modified: 2007-04-18 13:15 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHN 4.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-31 22:40:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Conklin 2004-11-16 13:21:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040924

Description of problem:
From IT#54400:

When I try to search for libtiff or libjpeg packages for the ia64, I
get to an ia64 page that instead offers me i386 packages for download.

Steps to reproduce:
log in to rhn.
select "packages" in the search field at the top of the page.
enter "libjpeg"
uncheck "Channels relevant to your systems" and check "ia64" (I don't
have any ia64 systems regestered)
click search again
select libjpeg
from the list that comes up, select "libjpeg-6b-30    Red Hat
Enterprise Linux AS (v. 3 for Itanium)"
The page that comes up has a title that says "libjpeg-6b-30.i386.rpm"
and i386 it indeed is.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. See description
2.
3.
    

Actual Results:  has i386 packages linked

Expected Results:  should have ia64 packages linked

Additional info:
Comment 1 Todd Warner 2004-12-02 21:42:49 EST
This issue is associated with this Bret:
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=54400
Comment 2 Robin Norwood 2005-02-08 12:38:29 EST
This happens because the ia64 channel has both the 32 bit and 64 bit
versions of libjpeg.  The arch selection on the first page of the
package search means to search in channels with the specified arch,
not the arches of the packages.

There isn't an easy way to make the ia64 package show up in this use case.

Two possible solutions:

o Add an 'affinity' column to the rhnChannelPackageArchCompat table,
so we can record the 'preferred' package arch for a given channel
arch, and give you that by default.  This might also help with
multilib issues, I think.

o Change the package search so we search by package arch, not channel
arch.  This would change the behavior of the search, and I don't know
if it is more right or not.

Moving this to 'ON_DEV' - not closing it yet so people can review the
above and complain if they want.
Comment 3 Bret McMillan 2005-02-08 12:56:48 EST
The problem here is the auto-guestimation of the desired package arch, correct?
 Why don't we simply show nvrea instead of just nvre and then guessing arch?
Comment 4 Robin Norwood 2005-02-09 14:00:59 EST
Well, that change is pretty easy to make - but the same problem exists
in pretty much every other place we list packages.  For instance, if
you navigate to RHEL3-AS for itanium, go to the list of packages
associated with that channel, and find libjpeg, you'll notice that
nvre is what is shown in that list also - and clicking on the package
name brings you to the i386 version.  I think we should keep the lists
consistent.
Comment 5 Robin Norwood 2005-02-10 15:09:34 EST
updating estimate to change all places where we show packages in a
channel to include arch - this includes the package download code.
Comment 6 Robin Norwood 2005-02-14 16:10:29 EST
The fix under discussion is to change lists that show the packages in
a channel (or channels) to display name-version-release:epoch-arch
instead of just name-version-release:epoch.  The package search page
in question is just one of the pages that would change.
Comment 7 Mike McCune 2005-02-15 15:18:56 EST
taking this bug and implementing comment #6.
Comment 8 Mike McCune 2005-02-15 16:36:23 EST
An example from the change I made shows the package name as follows:

4Suite-0.11-2-i386              
a2ps-4.13b-15-i386              
adjtimex-1.11-5-i386    	    
alchemist-1.0.18-1-i386 	    
alchemist-devel-1.0.18-1-i386 	
alien-7.24-3-noarch
Comment 9 Mike McCune 2005-02-15 19:34:52 EST
There were actually not that many channel pages that needed changing.  Some
already showed nvrea with the proper format.  I checked and only these needed
changing:

network/software/channels/packages.pxt
network/software/channels/manage/packages/add_confirm.pxt
network/software/channels/manage/packages/compare/sync_confirm.pxt

I also switched over to the . notation between the nvre and the a:

4Suite-0.11-2.i386   

as was suggested by Robin.

Made sure all the channel listviews that show the arch use the . instead of a -
(it was mixed, some showed - and some showed .).
Comment 10 Mike McCune 2005-02-15 19:52:47 EST
TEST PLAN:

Package list index:
-------------------
1) Nav to the Channels tab
2) Pick a channel with packages
3) Click the packages tab
4) Verify that the 1st column header indicates "Package"
5) Verify that the items under that list end with the arch value:

4Suite-1.0-3.i386
a2ps-4.13b-41.i386
acl-2.2.23-5.i386

the old way didn't have the .i386 on the end

5) Search for "i386" and verify that the returned result includes just i386
packages (or search for noarch, its usually a smaller subset)


Channel Managment
-----------------

1) On a Sat, login with a user who has Channel Administrator rights
2) Create a channel
3) Edit the Channel and go to "Add"
4) Select a different channel from the View drop list until you get a list of
packages
   you can add.
5) When the list displays make sure that the column header indicates "Package"
6) Verify that the items under that list end with the arch value:

4Suite-1.0-3.i386
a2ps-4.13b-41.i386
acl-2.2.23-5.i386

7) Select a package from the list, click "Add packages"
8) Verify that the next list contains the previously selected package and the
   column header is "Package".  
9) Verify that the items under that list end with the arch value.
10) Now select Compare from the navigation tab
11) Choose a channel that you know is different so you get items in the list
12) Once you get a set of different packages select "Merge Differences"
13) Leave radio button on "Make identical"
14) On the preview page make sure the 1st column header indicates "Package"
15) Verify that the items under that list end with the arch value
16) Select an item from the list and click Merge Packages. 
17) When the list displays make sure that the column header indicates "Package"
18) Verify that the items under that list end with the arch value.

DONE

Comment 11 Mike McCune 2005-02-15 19:56:51 EST
Adding actual hours worked and setting to ON_DEV
Comment 12 Fanny Augustin 2005-03-03 10:02:39 EST
Looks good on QA.
Comment 13 David Tonhofer 2005-03-28 17:33:17 EST
I can't wait for it to go into production.

Just stumbled over this problem with a EMT64T (wanted) vs i386 (not wanted)
architecture. Now I have the package twice on my system. Stupid me.

Well, I will just have to clean up. :-)
Comment 15 Todd Warner 2005-04-08 12:16:42 EDT
mass move: PROD_READY --> CLOSED:CURRENTRELEASE
Comment 16 Johnray Fuller 2005-04-08 12:28:04 EDT
So the QA test plan has a different methodology than what was asked for.
The new behavior in 3.7 is an improvement, however, can it be mapped over
to the search follwoing methodology:



- select "packages" in the search field at the top of the page.

- enter "libjpeg"

- uncheck "Channels relevant to your systems" and check "ia64" (I
don't have any ia64 systems regestered)

- click search again

- select libjpeg



From the list that comes up, select "libjpeg-6b-30    Red Hat Enterprise
Linux AS (v. 3 for Itanium)"
Comment 18 Mike McCune 2005-06-06 18:46:47 EDT
Cliff, IMHO this should be filed as a new bug since its not that the bug
described above wasn't fixed, it just sounds like they want an improvement on
what we did for this bug.
Comment 19 Johnray Fuller 2005-06-06 20:54:11 EDT
Actually, the original reproduction case was never solved. Refer to:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139562#c0

J
Comment 20 Mike McCune 2005-07-05 18:05:42 EDT
Discovered we are going to need database schema updates to support this change.
We don't currently store a 'channel preference' for arch.  

So, when the user clicks the link to view the package, in this instance
libjpeg-6b-30, the code chooses the first arch that is supported which happens
to be i386.  We are going to need a preference column added to the db to denote
which arch should be chosen when viewing packages.  Filed bug: 162536.

I assumed that this bug wouldn't be hard to resolve so I hadn't had a chance to
get to it until late in our 400 release.  Since this change will require a bit
of extra work and we are nearing the end of 400 we are going to have to push
this one off to 410.  
Comment 21 Mike McCune 2005-07-07 20:30:20 EDT
Moving back into 400.  I'm fairly certain I've found a solution to this bug as
well as 154743.
Comment 22 Mike McCune 2005-07-13 00:06:50 EDT
TESTPLAN:

TestCase A)
1) select "packages" in the search field at the top of the page.
2) enter "libjpeg"
3) uncheck "Channels relevant to your systems" and check "ia64" (I
   don't have any ia64 systems regestered)
4) click search again
5) select libjpeg
6) You should see a list of libjpeg packages plus their arch:

libjpeg-6b-30.ia64 Red Hat Enterprise Linux WS (v. 3 for Itanium)

7) You should also see a note at the top:

NOTE: Different architectures of the same package can exist in a single channel,
this may cause a package to be listed twice for a given channel.

8) Click on:

libjpeg-6b-30.ia64 Red Hat Enterprise Linux WS (v. 3 for Itanium)

verify that it goes directly to:

libjpeg-6b-30.ia64.rpm

TestCase B)

1) Login with an account that has systems registered to it.
1) select "packages" in the search field at the top of the page.
2) enter "libjpeg"
3) leave the "Channels relevant to your systems" item clicked
4) Click libjpeg in the list
5) Verify that the list comes back OK (no 500 errors)
6) On my account I saw a bunch of entries for i386 RPMs since that is what
   I had registered

TestCase C)
1) register an entirely new corporate account as part of a new org that has
   no systems registered at all.
2) select "packages" in the search field at the top of the page.
3) enter "libjpeg"
4) leave the "Channels relevant to your systems" item clicked
5) Click libjpeg
6) should just see:

libjpeg-6b-21.i386   	 Red Hat Linux 8.0 i386

TestCase D)  (OPTIONAL)

1) login to an account with systems registered
2) search for some other common packages such as kernel, glibc, gimp, etc..
3) Verify that the search pages return valid results
Comment 23 Vlady Zlatkin 2005-07-15 15:46:38 EDT
prod ready

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