Red Hat Bugzilla – Bug 132971
Cloning a channel clones multiple comps RPMs
Last modified: 2007-07-31 10:32:20 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040303 Description of problem: When we clone RHEL 3 WS we specifically select 'Clone Original State of Channel' This should clone all packages that are not specifically associated with a channel. For some reason, this clone 2 comps packages: comps-3ws-0.20031007 and comps-3WS-0.20040831:1 The first one is the correct one, the later one is from a much later update. See IT #48974 Version-Release number of selected component (if applicable): Satellite 3.4 How reproducible: Always Steps to Reproduce: 1.Clone RHEL 3 WS IA32 channel 2.Select 'clone original state of channel' 3. Actual Results: An updated comps package gets cloned into the channel as well as the original one. Expected Results: The original comps packages should have been cloned into the channel. Additional info: Workaround is to remove the incorrect package from the channel using standard channel management tools.
Nick, Looking at those two packages in the web UI: https://rhn.redhat.com/network/software/packages/details.pxt?pid=184872 (comps-3ws-0.20031007) https://rhn.redhat.com/network/software/packages/details.pxt?pid=263974 (comps-3WS-0.20040831:1) 184872 is the 'original' package, and 263974 is the updated package. So why are both showing up? If you look at the 'New Versions', you'll see that three new packages are listed - two of them are 'errata'd versions, and the third has no errata associated with it, and is our mystery package (263974). When we clone the original state of the channel, we look for packages with no errata associated with them.
Robin, I thought that was it - obviously an RPM that isn't associated with an erratum must have been in the original release, but this doesn't quite hold true of course, as there is a new comps file with each update. I suppose the fix would be to put a special case for comps in the package selection code. I (and the client) are a bit suprised this didn't come up in QA.
The fix for this is probably to do two passes when cloning the original state of a channel - All packages not referenced by an errata, then the the oldest version of each of those packages. That should do the right thing in this case. When cloning the channel 'as it is now', then we'll clone all the packages and errata, like we do now. However, I'm not quite certain how to handle the case of cloning 'some errata' - I don't think there's a 'correct' default behavior, so I'll probably have to ask the user.
we've externally committed to getting this done.
bug #135607 is fixed - and thus this bug. Test plan: Clone the original state of RHEL 3 WS - then go to the list of packages- there should be only one 'comps', package instead of two, as described above.
QA push. {ON_DEV,QA_READY} --> ON_QA
DOC notes: We should document the fact that previously, if you cloned the 'original' state of the channel, you could get newer packages than the original release if those new packages were not associated with an errata - like the 'comps' package above. Now, you should only get the newest version of each package that is not associated with an errata.
Looks good on QA.
Functionality has been tested and it is working... Setting the bug to QA_READY and waiting for clay to document it. Once it has been set to ON_QA, only the doc needs to be tested.
docs complete
Docs and functionalities looks good on QA.
Mass move from PROD_READY to CLOSED:CURRENTRELEASE
Closing ticket. Internal Status set to 'Resolved' Status set to: Closed by Tech Resolution set to: 'NotABug' This event sent from IssueTracker by racedo issue 48974