[Spacewalk-list] CentOS 5.2 - a warning]

[m.roth2006 at rcn.com]

John,

>Date: Wed, 22 Apr 2009 17:35:41 +0100 (BST)
>From: John Hodrien <J.H.Hodrien at leeds.ac.uk>  
>On Wed, 22 Apr 2009, m.roth2006 at rcn.com wrote:
>
>> Sorry, the kernel module may have been in there due to problems back when I
>> created the repository with reposync. However, at an official mirror, there
>> *are* serious i686 packages. See my response, below.
>
>Yes there are i686 packages in the x86_64 repo, and yes there should be.

That's interesting. Over on the Redhat list, I'm told there shouldn't be.
>
>> Well,yes, they are. I know what the 686's are. The big thing was this: when
>> they were in the Spacewalk repository, the query that Spacewalk did on its
>> d/b got them uniquely. So when I told it to upgrade, it did it with those
>> packages. Then, when I went to reboot, that failed coming back up, with the
>> error "request_module: runaway loop modprobe binfmt-464c" repeated three or
>> so times.
>
>That's a bug in the multiarch handling of spacewalk then.
>
That bug is in the 686 being installed. It was the install of the 686 that killed everything. 

For that matter, if there are multiple packages for the same piece of software, it seems to me that Spacewalk should show all of them, and highlight them, and show enough of the name that I know why there are multiple.
>> <snip>
>>>> On the other hand, when I click on a package name on the
>>>> system->software->upgrade page, expecting the same info that I see
>>>> system->software->going
>>>> through channels->packages, I get a 500 error.
>>
>>> It's almost like the reported bug against 0.4.
>>
>> Kindly note that I said I was running 0.4.
>
>Yep, I had noted that...  I really wouldn't run against 0.4 out of choice.  I
>used 0.1/2/3/5.  0.4 was fun for testing.

Not long after I walked in the door where I've been contracting, they told me to do Spacewalk. I went to the site, and 0.4 was the latest, greatest, and stable version. I saw nothing that suggested it was a development version, like the way the Linux kernel x.<odd> == dev, and x.<even> == stable.
>
>>> Multiarch sucks (sometimes), but there really isn't anything >wrong with
>>> our repositories regarding i686 packages (and >there is no i686 kernel in
>>> the 5.2/5.3 repositories). >Luckily the original poster didn't look for
>>> i386 packages <vbeg>.
>>
>> Wrong. At
>> <http://mirror.anl.gov/pub/centos/5.2/updates/x86_64/RPMS/>, I find
>> glibc-2.5-24.el5_2.2.i686.rpm (a real killer)
>> openssl-0.9.8b-10.el5_2.1.i686.rpm
>> xen-devel-3.0.3-64.el5_2.1.i686.rpm
>> xen-libs-3.0.3-64.el5_2.1.i686.rpm
>>
>> And at <http://mirror.anl.gov/pub/centos/5.3/os/x86_64/CentOS/> is
>> glibc-2.5-34.i686.rpm
>> openssl-0.9.8e-7.el5.i686.rpm
>>
>> So, they really are in the repository, and incorrect.
>
>No, you're not reading what either of us are writing.  There's nothing *wrong*
>with those i686 packages being in the repo.  They're there deliberately.  They
>should be there.  It is not some packaging bug you've spotted.

Then you and I have a disagreement. I *know* that when I did the upgrade, and got the 686 packages installed, it failed to successfully boot, and when I removed them, it booted with no issues at all. As far as I'm concerned, that is proof that it should not have been installed. That makes it a CentOS problem, not a Spacewalk problem, since they have packages in one repository that should not be there.
<snip>
       mark