[Spacewalk-list] Packages associated with wrong channel

[Jason M. Nielsen]

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):
>> http://sourceforge.net/projects/rhn2spacewalk/files/
>
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>

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
-------------- next part --------------
begin:vcard
fn:Jason Nielsen
n:Nielsen;Jason
org:Myriad Genetics, Inc.;IT
email;internet:jnielsen at myriad.com
title:Unix Administrator
tel;work:801-505-5123
tel;cell:801-782-7141
version:2.1
end:vcard