[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Spacewalk-list] Packages associated with wrong channel

On 04/06/2011 04:54 AM, Sander Grendelman wrote:
On Mon, Apr 04, 2011 at 02:18:42PM -0600, Jason M. Nielsen wrote:

After a long time of poking around I noticed a pattern and it appears to
be related to errata that were submitted into spacewalk. The script I
use is not capable of supplying a channel name so it is submitted to all
channels. I presumed that even with the errata in all channels it would
still only be the errata and only apply if the rpm existed in the
channel. Actually it would seem by pushing the errata to all channels it
results in those rpms becoming associated with the channel with one
exception. Architecture is held correctly. That is, Im not seeing x8664
rpms associated with i386 channels.

I realize that if this is what caused the problem then its the b0rked
script but what Im wondering is does Spacewalk automatically associate
an rpm with a channel just because errata for the rpm has been submitted
to that channel?

It seems to me that packages should only be associated to a channel by
an explicit push of some sort (in my case rhnpush) and no other reason.
It could be the script itself did this as one section looks like it very
well might be pushing packages and not just errata. Im completely
unfamiliar with the api though.

I've also run into this problem, it seems that publishing an erratum
to multiple channels can cause associated packages to be pushed to some
of those channels too. This can also cause centos5-packages to appear in
centos4 channels :(. A workaround is to publish the erratum without
associated packages and associating packages afterwards.

In my opinion this is a bug, I don't know if there is already a bugzilla
report for this one?

I tried disassociating the errata with the channels but the rpm still
shows up in the package list. Its looking like the only method to
reliably clean this up will be start from scratch. Maybe I can just wipe
the rhel4 channels.

If it was not the script and related to the errata then Im baffled as to
what caused this.

It is very probable that this was caused by the script, deleting the
packages should also work. You can probably search for packages with
"el5" in their name through the api and delete the resulting packages
from your rhel4 channels.

This is the script I used (get_errata.pl):

I don't see an errata-publishing step in this script but I do see that
errata are created with their relevant packages attached.

What works for me when publishing an erratum through the api is:

1) Create erratum _without packages_.
2) Publish erratum to the relevant channels.
3) Add packages to the erratum.

This way no packages are pushed to the wrong channel. An extra benefit
is that publishing the erratum without packages is a lot quicker.

Spacewalk-list mailing list
Spacewalk-list redhat com

The biggest problem with the manual association is when you are talking 1000s of errata its pretty well just not going to happen. Think Im going to try my hand at the api and my own scripts. If there is no way to automatically associate it all then errata be damned. Its not worth the grief. This is definitely a bug if the script did not push the package to the other channels.

So after closer inspection I have packages posted across all channels which basically means reconstruction of over 20000 packages and 16 channels. Ouch. Guess I just should not have trusted the script and knew more about it before running. Unfortunately when I tested it I only had a small number of packages and channels. There was probably no cross over for whatever reason.

What really sucks is I thought maybe I could just delete all packages across the board and at least keep my channel setup and activation keys. It would appear nothing is being removed from the satellite base directory and it just continues to grow in size so I very well might be stuck with a full blown wipe of all of spacewalk. Perhaps Ill just stick with a plain flat file http repo and yum. lol
fn:Jason Nielsen
org:Myriad Genetics, Inc.;IT
email;internet:jnielsen myriad com
title:Unix Administrator

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]