Bug 132971 - Cloning a channel clones multiple comps RPMs
Summary: Cloning a channel clones multiple comps RPMs
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Robin Norwood
QA Contact: Fanny Augustin
Depends On: 135607
Blocks: rhn360sat
TreeView+ depends on / blocked
Reported: 2004-09-20 15:17 UTC by Nick Strugnell
Modified: 2007-07-31 14:32 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2005-03-22 17:47:51 UTC

Attachments (Terms of Use)

Description Nick Strugnell 2004-09-20 15:17:00 UTC
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

See IT #48974

Version-Release number of selected component (if applicable):
Satellite 3.4

How reproducible:

Steps to Reproduce:
1.Clone RHEL 3 WS IA32 channel
2.Select 'clone original state of channel'

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.

Comment 1 Robin Norwood 2004-09-20 16:35:14 UTC

Looking at those two packages in the web UI:



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.

Comment 2 Nick Strugnell 2004-09-20 17:05:15 UTC

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.

Comment 4 Robin Norwood 2004-09-24 12:54:40 UTC
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.

Comment 6 Bret McMillan 2004-10-08 23:10:09 UTC
we've externally committed to getting this done.

Comment 8 Robin Norwood 2004-10-15 20:26:04 UTC
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.

Comment 9 Todd Warner 2004-10-21 16:37:33 UTC
QA push. {ON_DEV,QA_READY} --> ON_QA

Comment 10 Robin Norwood 2004-10-21 17:33:52 UTC
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.

Comment 11 Fanny Augustin 2004-11-23 18:44:35 UTC
Looks good on QA.

Comment 12 Fanny Augustin 2004-11-23 18:55:33 UTC
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.

Comment 13 Clay Murphy 2004-12-02 21:28:30 UTC
docs complete

Comment 14 Fanny Augustin 2004-12-06 14:16:36 UTC
Docs and functionalities looks good on QA.

Comment 15 Todd Warner 2005-03-22 17:47:51 UTC

Comment 16 Issue Tracker 2007-06-19 14:09:27 UTC
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

Note You need to log in before you can comment on or make changes to this bug.