2. What is the nature and description of the request? Customer would like to have a cut off date feature with yum where they are looking for to skip packages from the repositories with dates after the specified cutoff so that they can apply updates in a more controlled manner. 3. Why does the customer need this? (List the business requirements here) In an environment with many sets of "development/quality assurance/production" servers, it is important to have a simple mechanism for applying updates to dev, then later to qa then later to production. While clones of the satellite distribution channels can be made, this creates extra work and causes it's own short-comings. By providing a mechanism within yum itself, each department or group responsible for maintaining these different servers can easily set their own schedules of when updates get applied, while still providing the transparency of what updates are available. Providing this feature from yum itself simplifies the scheduling and application of a centralized repo without the need for creating clones channels. 4. How would the customer like to achieve this? (List the functional requirements here) Customer would like to control feature on updates provided by yum by introducing a cut off date feature. A new option on yum like --cutoff-date yyyy-mm-dd would cause yum to skip files from the repos with dates after the specified cutoff. 5. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Once implemented, we can test the feature of yum by specifying cut off dates and skip the packages and apply it in a more controlled manner. 6. Is there already an existing RFE upstream or in Red Hat bugzilla? No 7. How quickly does this need resolved? (desired target release) Minor release 8. Does this request meet the RHEL Inclusion criteria (please review) Yes 9. List the affected packages yum
> Customer would like to have a cut off date feature with yum where they are > looking for to skip packages from the repositories with dates after the > specified cutoff so that they can apply updates in a more controlled manner. The problem is that the information they want is: What is the date that a package was added to a repo. ...and yum doesn't have that. We have builddate, but that is not the same. > 3. Why does the customer need this? (List the business requirements here) > In an environment with many sets of "development/quality assurance/production" > servers, it is important to have a simple mechanism for applying updates to > dev, then later to qa then later to production. Right, so what they really want isn't this date thing IMO. In RHEL-6.1 yum will have this ability: Machine 1: yum update [yum spits out a file like yum_save_tx-2011-02-07-11-44eQMtZk.yumtx in $TMPDIR] Machine 2: [much time later] yum load-ts yum_save_tx-2011-02-07-11-44eQMtZk.yumtx ...which will be the same transaction that happened on "machine 1", even if there are newer versions of packages. I have a RHEL-5 repo. which has a build from rawhide in it (on repos.fedorapeople.org) ... so they can see what this works like. This feature is unlikely to get backported to RHEL-5 though.
(In reply to comment #2) > Right, so what they really want isn't this date thing IMO. > In RHEL-6.1 yum will have this ability: This sounds like a very reasonable approach to handling this requirement which I suspect is a common one for environments using DTAP <http://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production> workflows. Abhilash, you own the communication with the customer behind this request - can you please check with them whether the ability that James describes in comment #2 meets their needs?
I just sent a patch upstream to store the yum transaction save file in the add on history store so you can retrieve the transaction file from any transaction in the historydb.
This enhancement request was evaluated by Red Hat Product Management for inclusion a Red Hat Enterprise Linux maintenance release. Red Hat does not currently plan to provide this enhanced functionality in a Red Hat Enterprise Linux update for currently deployed products. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects. For more information on Red Hat Enterprise Linux maintenance policies, please consult: https://access.redhat.com/support/policy/updates/errata/ Red Hat values your feedback and will take this enhancement request into consideration for future major releases of Red Hat Enterprise Linux.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.