Bug 139562 (IT#54400)

This issue is associated with this Bret:
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=54400

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.

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?

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.

updating estimate to change all places where we show packages in a
channel to include arch - this includes the package download code.

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.

taking this bug and implementing comment #6.

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

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 .).

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

Adding actual hours worked and setting to ON_DEV

Looks good on QA.

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. :-)

mass move: PROD_READY --> CLOSED:CURRENTRELEASE

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)"

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.

Actually, the original reproduction case was never solved. Refer to:

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

J

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.  

Moving back into 400.  I'm fairly certain I've found a solution to this bug as
well as 154743.

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

prod ready