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
