[Spacewalk-list] Clone errata with pkgs of another channel.

Nilton Moura redhat at nmoura.eti.br
Fri Jan 27 20:24:23 UTC 2012


Thank you.

I'm trying to do this, but I guess you will finish early. How do you think
you'll do this? With a new method or only changing the script? I'm
searching a method to acomplish, but on getDetails for instance, I need to
know the id. So, if I lookup with Nvrea and check the vendor or provider
with getDetails, and after come back to a new lookup with Nvrea.. but I
think this shouldn't work cause it will bring the same result, and sounds
ugly too.

Can you give me some light?

Thanks.

2012/1/27 Speagle, Andy <andy.speagle at wichita.edu>

>  Hi Nilton,****
>
> ** **
>
> That’s a good catch… that has never been an issue for me since I don’t
> have mixed vendors on my system.  I’ll get this updated and put out a patch
> as soon as I can.  Thanks for sharing your usage case.****
>
> ** **
>
> Andy****
>
> ** **
>
> *From:* spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] *On Behalf Of *Nilton Moura
> *Sent:* Friday, January 27, 2012 11:49 AM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] Clone errata with pkgs of another channel.
> ****
>
> ** **
>
> Hi.****
>
> ** **
>
> I've been reading the python-clone-errata.py and I see that it uses the
> findByNvrea method. Can I create another method like this, adding vendor or
> provider parameter? I guess this will solve my problem, which is the first
> entry matched on database is returned, no matter the channel. (I debug with
> some prints on the script and comparing with the id's on the database).***
> *
>
> ** **
>
> If not, the another "solution" (workaround), is to first upload packages
> from RHN than the CentOS for example (but this sounds very ugly).****
>
> ** **
>
> Thanks,****
>
> Nilton Moura.****
>
> 2012/1/26 Nilton Moura <redhat at nmoura.eti.br>****
>
> Hi,****
>
> ** **
>
> I'm cloning erratas from RHN with rhn-clone-errata.py 0.9.0 by Andy
> Speagle, but some erratas are being associated with packages from another
> channel (when the same package exist on CentOS for example).****
>
> ** **
>
> For example, after publish the errata RHSA-2012:0060 from
> rhel-5-x86_64-server, I go to Packages and the GUI shows me only one
> package (openssl-0.9.8e-20.el5_7.1-i686), but if I go to Packages in Manage
> Errata, the list appears different:****
>
> ** **
>
> openssl-0.9.8e-20.el5_7.1-i686 RHEL x86_64 Server (v. 5) rhn ****
>
> openssl-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates ****
>
> openssl-devel-0.9.8e-20.el5_7.1-i386 CentOS x86_64 (v. 5) updates ****
>
> openssl-devel-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates ****
>
> openssl-perl-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates****
>
> ** **
>
> I uploaded two prints with this to better understanding:****
>
> ** **
>
> -> http://static.inky.ws/image/1180/image.jpg****
>
> -> http://static.inky.ws/image/1181/image.jpg****
>
> ** **
>
> If I manually remove this CentOS packages from the errata and add the
> corrected packages from rhel channel I correct this.****
>
> ** **
>
> Thanks,****
>
> Nilton Moura.****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20120127/5498bfac/attachment.htm>


More information about the Spacewalk-list mailing list