Now that there is enough information i looked and found an exiting bug ticket for this
https://bugzilla.redhat.com/show_bug.cgi?id=834569 On Thu, Nov 22, 2012 at 12:58 PM, Paul Robert Marino <prmari...@gmail.com> wrote: > well here was an intresting and succesfull experiment > I manually added the packages to the errata via sql > " > spaceschema=# select id from rhnErrata where advisory_name like > 'SLBA-2012:1302'; > id > ------- > 29954 > (1 row) > > spaceschema=# select * from rhnerratapackage where errata_id = '29954'; > errata_id | package_id | created | modified > -----------+------------+-------------------------------+------------------------------- > 29954 | 107482 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 > 18:12:48.351349-05 > 29954 | 107483 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 > 18:12:48.351349-05 > (2 rows) > > spaceschema=# insert into rhnerratapackage > (errata_id,package_id,created,modified) > VALUES(29954,107890,'2012-11-21 18:12:48.351349-05','2012-11-21 > 18:12:48.351349-05'); > INSERT 0 1 > spaceschema=# insert into rhnerratapackage > (errata_id,package_id,created,modified) > VALUES(29954,107889,'2012-11-21 18:12:48.351349-05','2012-11-21 > 18:12:48.351349-05') > ; > INSERT 0 1 > spaceschema=# > > " > > then I refreshed the page listing the packages in the errata > and I got this > " > CentOS 6 FastTrack (x86_64) > sha256:e85a76b7a959db0566c656b82fb4ad69ddec2ab448e111086716c63e18945c33 > cvs-1.11.23-15.el6-x86_64 > sha256:455178ca3ab78b5f0403da16f4512ac9f5d2481e191329f5b7f02ef7b05b2423 > cvs-inetd-1.11.23-15.el6-noarch > > Scientific Linux 6 Updates FastBug (x86_64) > sha256:b2c4eeb020973c966747ccbd2711ae8f25f1f35f2be12211e21ba4118fef4e2f > cvs-1.11.23-15.el6-x86_64 > sha256:d09f12ee26dada51aafa210846c120dff2fab3a8ff17ec1fb6d510677cfb6784 > cvs-inetd-1.11.23-15.el6-noarch > " > It works so I'm now leaning in the direction that this is an API bug > because clearly its possible > > I think we now have enough to put together a bug report > I just have one more test i want to do to complete it but it seems > like this may be fixable. > > > On Wed, Nov 21, 2012 at 5:33 PM, Paul Robert Marino <prmari...@gmail.com> > wrote: >> Well I understand your point about mixing distros but more often than >> not often they are the same and with Scientific Linux they are always >> the same as RHEL's. >> also there is a bigger concern mixing architectures and releases in a >> single errata is common place even in RHN. >> Ive seen instances where a 32bit library or app on x86_64 requires a >> 64bit dependance on the x86_64 version of the distro this happens for >> various reasons. Ive also seen instances where onarch packages weren't >> actually architecture independent this often happens with Perl modules >> where a new version added XS code and the package maintainer didn't >> catch it. In these cases it would represent a significant problem. >> >> >> >> >> >> On Wed, Nov 21, 2012 at 3:20 PM, Franky Van Liedekerke >> <liede...@telenet.be> wrote: >>> On Tue, 20 Nov 2012 22:28:07 -0500 >>> Paul Robert Marino <prmari...@gmail.com> wrote: >>> >>>> I'm not sure if I should classify this as bug or an rfe but either >>>> way ill put in a ticket tommorow. I ran into an intresting problem. >>>> There is a common case where you have for example centos channels and >>>> scientific linux channels where you may have different packages with >>>> the same name in different base channels. >>>> It would be nice to be able to publish a single errata with multiple >>>> base channels from different distros that could cover them all but >>>> what I've found in testing is there seems to be no way to do that >>>> safely. When you try to do that the package from one channel gets >>>> published into the other resulting in a duplicate package in the >>>> other channels the first one being the original package for that >>>> distro the second being the package from the first channel. >>>> This is actually a common problem and complaint for most of the >>>> errata sync scripts. The resultt is it breaks yum and by extention >>>> anacondas ability to use the channel. >>>> After a bit of investigation I found it was a limitation of the api, I >>>> haven't dug into the database yet but. This is something that needs >>>> investigation because it would eleviate a lot of the dificulties >>>> users have with the errata sync scripts. >>> >>> Why try to "combine" errata's from different distro's? It seems like >>> a very bad idea: one should know for which distro/base channel the >>> errata is. And a CentOS errata might totally not be related to a redhat >>> errata, even if it has the same name (the packages might be different). >>> The way I coded it up: get a list of packages per channel and then >>> compare these with the ones mentioned in the errata. Easy and >>> simple ... of course I only do one-on-one channel errata sync, but it >>> never failed me yet. >>> For those interested (shameless adv): one errata script for both redhat >>> and/or centos errata sync's, without cross contamination issues and >>> with proxy support (but only one channel at the time): >>> https://github.com/liedekef/spacewalk_scripts >>> >>> Franky >>> >>> _______________________________________________ >>> Spacewalk-devel mailing list >>> Spacewalk-devel@redhat.com >>> https://www.redhat.com/mailman/listinfo/spacewalk-devel _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
