[Spacewalk-list] content provider for packages

[Paul Robert Marino]

Well I'm not sure the people at centos are making the mistake. I've seen
this happen using some errata sync scripts. Basicly the errata sync script
finds an rpm with a name that matches the errata in a different base
channel and republishes it to the wrong base channel. It usually causes the
redhat. Packages to get published to centos and or scientific linux
channels.
On Aug 20, 2012 8:43 AM, "Franky Van Liedekerke" <liedekef at telenet.be>
wrote:

> Hi all,
>
> I manage, amongst other things, also CentOS channels in spacewalk. But
> sometimes the people at CentOS mess up and they push redhat updates in the
> CentOS channels. Of course these fail to install since the redhat GPG key
> is not installed for CentOS servers.
> Now I wrote a small script that attempts to find these packages, but here
> the problems begin:
>
> - the API call channel.software.**listAllPackages never returns the
> vendor or content provider (apparently the content provider is based on the
> signed GPG key), so I do a packages.getDetails call. But this call only
> gives me the vendor. Apperently some packages for CentOS still have redhat
> marked as vendor, so I'm not able to use this.
> - second try: doing the API call packages.search.**advancedWithChannel.
> This should return me the content provider, but since I can't search on the
> provider field, or I can't seem to search on a wildcard in the name field,
> this doesn't give me a list of the packages I want either
>
> So my question is now: is there a method to get a list of all packages in
> a channel belonging to a specific "content provider"?
>
> Franky
>
> ______________________________**_________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/**mailman/listinfo/spacewalk-**list<https://www.redhat.com/mailman/listinfo/spacewalk-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20120820/8a2a8a06/attachment.htm>