Description of problem:
See issue tracker 88813 for additional details.
Particularly for update releases, the redhat-release package should be marked as
Incompatible with versions of bundled packages that predate the release. Besides
the aesthetics of upgrading redhat-release actually begin meaningful, this would
presumably allow for useful dependency solving such as 'yum update redhat-release'.
This has the additional side effect of blocking accidental installs later on.
Its perfectly possible for a machine installed originally from an update (ie.
4.5) to have a 4.0 package installed without warning the user of their error.
Steps to Reproduce:
fs2:~ # cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 1)
fs2:~ # rpm -q openssl
fs2:~ # rpm -q redhat-release
fs2:~ # rpm -Uvh
V3 DSA signature: NOKEY, key ID db42a60e
Preparing... ########################################### [100%]
1:redhat-release ########################################### [100%]
[root@fs2 ~]# rpm -q openssl
fs2:~ # ls /systems/jumpstart/Redhat/WS4.0/i386/RedHat/RPMS/openssl-[0-9]*.rpm
"openssl version < 0.9.7a-43.2 is incompatible with redhat-release-4WS-3".
Clearly this would only apply to packages that were bundled and subsequently
updated. Across major releases there may be too many details to sort out, but
for updates this should be both simple and safe.
I don't believe this is an appropriate change to make at this stage in RHEL4's
life-cycle. Furthermore, this approach seems to be an abuse of the rpm Conficts
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.
If there's any abuse of rpm here, its redhat-release itself -- wrapping a
versioned package around a one-line text file seems rather pointless. If the
intent of that package is to leverage the package database to convey a release
level, then it should actually be used for that. As-is, it's a useless placeholder.
The statements "this is fixed in RHEL4 Update 4" or "VendorX hardware will only
be recognized in RHEL Update 3 and later" are apparently worthless, since all
that is required to upgrade a 4.0 install to the latest and greatest is to rpm
-U redhat-release. If that's incorrect, and in fact there's a whole body of
packages and updates that represent "RHEL Update 3", then why not reflect it in
the one and only one package that update version is noted, which happens to be
the one and only thing that package is for?
Agreed that its late in 4 to do this now, it apparently hadn't made it out of
Issue Tracker for the 15 months prior to comment 0. However the proper response
then is to bump it to a 5.1+.
Feel free to re-close if you agree that the redhat-release package serves no
redhat-release actually contains a number of files besides /etc/redhat-release.
It serves several purposes.
While I still have my concerns about this feature request, I am marking it for
consideration for a RHEL5 update.
I should note that there is some work underway that may solve the problem you're
getting at in a different way.
re comment 5 -- sorry, I obviously overstated in comment 4, but I believe you
follow the rationale. While I'm not familiar with the "work underway", I might
be willing to defer to that. My present concern is the system's lack of
enforcement (or even cognizance) of OS release/update, and manipulating this
pacakge seemed to be the most direct means of implementation. Thanks for giving
This FutureFeature bugzilla was not resolved in time for RHEL 5.2 Beta.
It has been moved from 5.2 to 5.3.
I would like to NAK this for RHEL 5 as well. The proposed change is significant
and is very likely to cause problems for customers. I understand the desire to
audit/prevent older packages, but I don't believe that redhat-release is the
right place for that. I propose that we create a new bug that is a feature
request targeted at RHEL 6.
Per the comments in #13, I agree and am moving this to RHEL6 instead.
This would (theoretically) be best done at the yum/yum-utils level, that could check all packages against what's in the repos to see what they correspond to, where they were installed from, etc. However, the necessary information doesn't appear to be in RHN which would make this doable sanely, as of right now.
Does rhel ever abandon a package w/o providing a way out/up?
How would a user who is regularly updating their system ever get into a situation that this feature would solve?
So a couple of questions:
1. Given that we have 5.2.z channels ... why doesn't "yum list updates" do what you want, when subscribed to the right channel?
2. If you have package Foo, that has foo-1.1 in 5.0, foo-1.2 in 5.0.1 (due to a security update), foo-1.3 (due to feature requests) in 5.1. It's _very_ possible that a customer will want to install 5.1/5.2 ... but only have foo-1.1 installed.
...also there's no way for yum to know what "point" release we are on, atm. ... we'd have to parse out the second digit from the redhat-release package.
And, as notting says, there's no information from RHN about what point release(s) a package is for.
This is normally done via. what repos/channels you are subscribed to, why isn't that enough?
re comment 17 --
#1 -- the common case would be that package isn't being installed via yum and perhaps came from media, direct download from RHN, local stash, etc. This would be an install of a previously uninstalled package, this is not an update.;
#2 -- Hardly. The user w/ those specific requirements isn't interested in running 5.1/5.2, clearly they're dealing with a rigid environment that has only approved the package set included in 5.0.1. Alternatively they have encountered a regression between foo-1.3 foo-1.2 and there is a support case warranted.
#2a -- If that case is generally honored, then Redhat needs to inform 3rd party software that "requires RH5.2 or later" means little more than redhat-release for 5.2 has been installed and that there is no guarantee that any other package has been incorporated from that release.
With regard to your follow-on, this is exactly why this was entered as a request against redhat-release, -not- yum. If redhat-release enumerates itself as 'incompatible' with release-bundled packages whose version is < than the version shipped w/ that release, then the user will get a graceful error. This actually gives a guarantee and meaning to an upgraded redhat-release; namely, it addresses two cases:
1) The redhat-release package won't be upgradable (as a result of RPM) to 5.2 until all packages bundled w/ 5.2 are >= the version that shipped w/ that release. This is a feature. Presently, letting a redhat-release package slip into a yum repo used for updates makes it immediately irrelevant (as it will be updated irrespective of the state of installed packages).
2) Once redhat-release _has_ been upgraded, a user who attempts to install a package whose verion pre-dates one that was bundled w/ that release will get an error that 'foo version < 1.3 is incompatible with redhat-release version 5.2'. This will give them the opportunity to either:
1) realize that they have an old version of foo that probably isn't what
2) downgrade redhat-release
3) throw caution to the wind and --force away
A couple more things about this:
1. yum list extras
List the packages installed on the system that are not available
in any yum repository listed in the config file.
2. yum list updates; yum list obsoletes
tells you if you're not current vs what your repos have.
Is that a good place to start for auditing installed pkgs?
> Hardly. The user w/ those specific requirements isn't interested in
> running 5.1/5.2, clearly they're dealing with a rigid environment that has
> only approved the package set included in 5.0.1
There are generally two sets of customers I see:
1. Runs "yum update -y", whatever RH/CentOS releases, is assumed good. Might also do that but are on specific channels like 5.1.z instead of just 5.y.
2. Does an install, and then only updates specific packages for specific problems. Might also have less red tape for security updates.
...which is why this BZ confuses me, I don't see the usecase for being on 5.y and wanting just 5.2 ... instead of just being on 5.2.z.
> If that case is generally honored, then Redhat needs to inform 3rd party
> software that "requires RH5.2 or later"
Ok, this seems interesting ... so you're saying that really the feature required is: ISV FOO wants to create a package which can only be installed on at least "RHEL-5.2", without specifically listing their requiring packages with >= the 5.1 release version?
Then, yeh, maybe having the redhat-release file conflict with the older versions of everything that got updated is the "best" way to go ... but the feedback the user will see isn't going to be optimal.
I am moving this to a distribution BZ for now. It may come back to redhat-release.
Historically, redhat-release has been updated via yum update/up2date as part of maintaining a system in sync with the latest errata. No package dependencies have ever existed for redhat-release on the vast majority of components.
RHEL minor releases were treated as aggregation points in a stream of updates during a lifecyle, although each errata in the update is relatively independent.
Rather than overloading the rpm dependencies to provide aggregation information, I would like to suggest a text file containing the minor release manifest and script to check the installed NVR vs the selected manifest.
Minor note - within Spacewalk we have a script which takes each released Enterprise Linux set of packages and allows our users to clone/create custom channels based on installation media set of contents:
(data within data dir, above link is to the scripts we provide).
Earlier in this bug it was talked about providing a script/audit tool. I feel this may be appropriate, if maybe the redhat-release shipped a file which contained the manifest of packages for that version and then an audit tool is executed which does a glorified diff between the rpm DB and the redhat-release provided data and report back on installed packages those which are older, newer, exact.
People can then choose to either resolve differences or take no action.
just an idea.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.
The comment above is incorrect. The correct version is bellow.
I'm sorry for any inconvenience.
This request was NOT resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you need
to escalate this bug.