cloneErrataAsOriginal is the right way to go and should simplify that function
quite a bit; I have some custom scripts at work that are using that call to
manage errata and can confirm it works was expected. IIRC that call wasn't
around when I wrote spacecmd or I was retarded for not using it.
/aron
-----Original Message-----
Message: 2
Date: Tue, 21 Feb 2012 11:17:02 +0000
From: Steven Hardy <sha...@redhat.com>
To: spacewalk-devel@redhat.com
Cc: aronpars...@gmail.com
Subject: [Spacewalk-devel] Question : spacecmd
softwarechannel_adderrata - cloneErrataAsOriginal
Message-ID: <1329823022.12900.38.ca...@shardy.csb>
Content-Type: text/plain; charset="UTF-8"
Hi All,
I'm currently trying to fix a problem with spacemd softwarechannel_adderrata,
and need some help understanding the correct way to handle this using the
latest API calls:
Currently, if you try to add errata from a RHEL5 base channel into a clone
channel, and the errata contains both EL5 and EL6 packages, you end up with EL6
packages in the EL5 clone channel (same happens if you publish the errata).
I think this is essentially never what you want, and AFAICT this should be
worked-around by using the cloneErrataAsOriginal API call.
However the current logic is spacecmd is this:
1 - Get list of packages in the errata
2 - do a channel.software.mergeErrata, or clone each errata using errata.clone
for older API versions
3 - Add the packages found in (1) to the destination channel
I think all of these steps can essentially be replaced by a call to
cloneErrataAsOriginal - is this correct?
Aron - can you also confirm if you are happy for the default behaviour of
softwarechannel_adderrata to switch to using cloneErrataAsOriginal (for API
versions which support it)?
I'm proposing to "fix" the softwarechannel_adderrata command, so that it uses
cloneErrataAsOriginal, then leave the errata_publish option as it is, as the
publishErrataAsOriginal call seems to require a clone errata anyway, and I
guess it may be useful to have the capability to do a "raw" publish in some
circumstances.
Any thoughts or information much appreciated!
Steve
------------------------------
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
End of Spacewalk-devel Digest, Vol 45, Issue 15
***********************************************
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
