Bug 1000945 - spacewalk-clone-by-date manual page shows wrong information
spacewalk-clone-by-date manual page shows wrong information
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Usability (Show other bugs)
550
All Linux
low Severity low
: ---
: ---
Assigned To: Grant Gainey
Red Hat Satellite QA List
:
Depends On:
Blocks: 462714
  Show dependency treegraph
 
Reported: 2013-08-26 03:34 EDT by khaled
Modified: 2017-04-28 08:34 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-28 08:34:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description khaled 2013-08-26 03:34:40 EDT
Document URL: 

Section Number and Name: 

Describe the issue: 
man spacewalk-clone-by-date says:
This means that since spacewalk-clone-by-date will grab only packages associated with an erratum, not all packages at a certain date will get cloned.

Suggestions for improvement: 
Remove the sentence 

Additional information: 
I have created a custom channel with few packages without any erratum associated to any of them. After cloning the channel with spacewalk-clone-by-date I noticed that all the packages have been cloned.
Comment 1 Clifford Perry 2013-08-26 09:59:47 EDT
Within bug: 

[Bug 966644] Man page update for spacewalk-clone-by-date adding packages having issue-date beyond what is specified with -d option

We changed from:

Please keep in mind that not all packages are associated with an erratum. This means that since spacewalk-clone-by-date will grab only packages associated with an erratum, not all packages at a certain date will get cloned.


to: 

Also note that spacewalk-clone-by-date will pull in any packages needed to resolve dependencies for any errata being cloned. Since dependency-resolution selects the "best" package to resolve dependencies, it is possible for the cloned channel(s) to end up with packages that are not directly associated with any errata, and which are newer than the specified date. This is expected behavior. </para>


Your noted use case within comment #1 is due to how the API's behave, in creating/cloning a channel, based on orgional/current state and/or then cloning the collection of Errata afterwards. If you are cloning a cloned/custom channel, then this tool may not behave how you are expecting, since it was designed for usage with main RHEL channels sync'd by customers into their Satellite. 

Cliff
Comment 3 Grant Gainey 2017-04-28 08:34:29 EDT
THis should have been closed at #c1 time

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