0002481: Incorrect /etc/redhat-release

Notes
(0006440) jds2001 (reporter) 2007-12-03 05:41	upstream lsb_release -a: [jstanley@luci ~]$ lsb_release -a LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.1 (Tikanga) Release: 5.1 Codename: Tikanga

(0006442) jhughes@hughesjr.com (administrator) 2007-12-03 12:50 edited on: 2007-12-03 12:52	we are trying something new to correspond to an upcoming 5.y.z release scheme from upstream. in the scheme, there will be a 5.1.z and 5.2.z tree ... those trees will be available for an extended period of time (5.1 and 5.2 ... each with different updates). so ... for that time we will off 3 things ... a 5 tree (same as now), a 5.1 tree (5.1 for the lifetime of the 5.1 tree) and a 5.2 tree (5.2 for the lifetime of that tree). Notice is says 5 and not 5.0 or 5.1 or 5.2 That means that if it says 5 ... you are the default tree ... if it says 5.1 you are on the 5.1 ONLY tree ... 5.2 you are on the 5.2 ONLY tree, etc. the way to tell your exact centos release is to do this command: rpm -q centos-release

(0006443) jhughes@hughesjr.com (administrator) 2007-12-03 12:53	also ... we are not exactly sure how or even when upstream will do this z tree thing. However, based on what we know right now .. this seems the cleanest way to prepare for implementation.

(0006444) ripienaar (reporter) 2007-12-03 12:56	Thank you, that makes sense. Perhaps something to clarify in the release notes though as this is a departure from what is expected behavior, even if when explained it makes sense.

(0006448) jds2001 (reporter) 2007-12-03 19:22	That only sort of makes sense. The upstream EUS stuff, from what I understand, will literally be versioned 5.1.z, 5.2.z, etc, so that you can easily tell an EUS system from a "mainline" one. As near as I know or could imagine, this would be accomplished by assigning the system to a different base channel on RHN (or in our case, perhaps by installing a different centos-release file that points to the new repo, and would contain an appropriate /etc/redhat-release). I still believe that the mainline /etc/redhat-release should reflect the update level of the system, if for no other reason than to maintain consistency with upstream, and lessen user confusion.

(0006452) jhughes@hughesjr.com (administrator) 2007-12-04 00:23	well ... we were less confused with 5, 5.1 and 5.2 :D we do not have any intention of doing 5.1.1 or 5.1.2, just 5.1 ... and maintaining it while it is maintained upstream. Also ... people are all the time updating redhat-release with any number of things to make it look like upstream for certain programs, etc. I am not sure how "rpm -q centos-release" is any harder than "cat /etc/redhat-release"

(0006453) smooge (developer) 2007-12-04 00:48	Various 3rd party software coughOracle?cough makes the assumption off of cat /etc/redhat-release and I know the DOD STIGS use that file also for their configurations. Now that may be based off of LSB which would be patching lsb_release to do the right thing.

(0006456) ripienaar (reporter) 2007-12-04 08:10	jhughes: 5, 5.1 and 5.2 makes sense, it would make more sense if centos 5.1 said 5.1 though cos currently the convention is just confusing. Whats been gained with introducing 5.1 only when upstream does 5.1z or whatever it will be? Why not do it now?

(0006469) kbsingh@karan.org (administrator) 2007-12-04 12:40	ripienaar, think about it - a Release 5 indicates a release 5 install, and a 5.1 or 5.2 would indicate that the machine is only in that branch and wont move to mainline /5/ unless there is some manual work done by the administrator. Thats not hard to comprehend. Also, we do not plan to - as Johnny has already pointed out - do any 5.1.1 or 5.1.2 or 5.1.3 releases, since again that would be counter productive and leave users with a false sense of security thinking they have the latest patch levels for each machine - when they might not. You also need to consider use-case's in non sync situations, wherein a user installs from 5.0 media and runs a yum update, when /5/ on the mirrors points at 5.2/ - in that case the ONLY sensible option is to reflect the reality in redhat-release, and say its Release 5. This isnt as much of an issue with Release 3 and 4 since there are no branches for people to put their machines into. We are still working on options to best handle a machine state when a branch is EOL'd. Conversation about that in the centos-devel mailing list please.

(0006485) sgao (reporter) 2007-12-05 20:33	What about "cat /etc/issue"? This command no longer works either. There are some problems with setting up yum repos. Here are some example I use for yum: baseurl=ftp://local.yum.server/pub/centos/$releasever/os/$basearch/ [^] The $releasever is grabbed from /etc/issue or /etc/redhat-release. The change will break this setting. Also users can't tell whether it's 5.0 or 5.1 easily. It's ok to change. However, at least maintaining a backward compatibility for some time is necessary to allow people adjust and change scripts that depend on old settings. Simon

(0006486) jhughes@hughesjr.com (administrator) 2007-12-05 21:40	ummm .... rpm -q centos-release is what populates $releasever THAT is exactly what we are talking about. if/when people want to move off the standard 5 tree ... to a 5.1 for life or 5.2 for life tree ... THEN ... $releasever for them would be 5.1 or 5.2 ... $release value for everyone that stays on 5 will be 5 forever. that is the whole point ... and it is totally backwards compatible. 5.1 is just (at this point) an upgrade to 5, not a really separate tree. When / if upstream makes this move ... 5.1 and 5.2 and 5 will all be separate trees and releases

(0006542) rayvd (reporter) 2007-12-11 17:46	I still have a problem with $releasever in my yum.conf files. Supposedly it pulls the release from redhat-release RPM (I changed it to pull from centos-release). However, it's still using '5' even though my centos-release RPM is centos-release-5-1.0.el5.centos.1. Perhaps this is because: # rpm -q --queryformat '%{VERSION}\n' centos-release 5 My distroverpkg is set to centos-release. In the short-term I am just manually changing my repo files to use 5.1 instead of $releasever, but just a bit annoying.

(0006543) ripienaar (reporter) 2007-12-11 17:51	rayvd: Thats a perfect example of why this is a terrible idea. In my setup too, some machines are on 5.0 and I want to keep them on 5.0 now because they are important or I cant get downtime or whatever, and some I want on 5.1. Now I need to go and roll out different yum repos to all these machines instead of being able to just have a std yum repo that will point machines at the right place :(

(0006544) rayvd (reporter) 2007-12-11 18:06	Maybe the right thing to do is to modify yum to pull in the %{RELEASE} as well as the %{VERSION} as a potential variable.

(0006545) kbsingh@karan.org (administrator) 2007-12-11 22:25	rayvd, it might be a good idea to work out what you are doing before you do it. The part you seem to be missing completely is that centos/5/ _IS_ /centos/5.1/ this is nothig new, its ALWAYS been like that with every centos release so far.

(0006549) dgoldsmith (reporter) 2007-12-12 04:49	I think part of the confusion comes in with regard to using public mirrors or using your own mirrors. We have local copies of the CentOS 4.x yum repositories and also of CentOS 5. For CentOS 4.x, we had a '4' symlink to whatever the latest version of CentOS 4.x was. Right now we have '5' being a symlink to 5.0. Once we pull a copy of 5.1, do we leave '5' as a symlink to 5.0 or do we need to repoint it to the 5.1 tree? Are new updates now being published to 5.0, 5.1, 5.x whenever they are released? When I look at the mirror at centos.arcticnetwork.ca, I see what looks like directories for 5.0, 5.1 and 5. Is '5' a directory or a symlink? If I look at the updates/i386/RPMS directory under each, the contents of '5' and '5.1' appear to be the same -- and this is a much shorter list than what is in 5.0/updates/i386/RPMS.

(0006620) rayvd (reporter) 2007-12-30 00:51	I see this has in fact been the same all along. My mistake. I do note however that RHEL 5.1 /etc/redhat-release includes the minor version number. Red Hat Enterprise Linux Server release 5.1 (Tikanga)

Issue History
Date Modified	Username	Field	Change
2007-12-02 23:57	ripienaar	New Issue
2007-12-02 23:57	ripienaar	Assigned To	=> kbsingh@karan.org
2007-12-03 05:41	jds2001	Note Added: 0006440
2007-12-03 05:41	yusufg	Issue Monitored: yusufg
2007-12-03 12:50	jhughes@hughesjr.com	Note Added: 0006442
2007-12-03 12:52	jhughes@hughesjr.com	Note Edited: 0006442
2007-12-03 12:53	jhughes@hughesjr.com	Note Added: 0006443
2007-12-03 12:56	ripienaar	Note Added: 0006444
2007-12-03 19:22	jds2001	Note Added: 0006448
2007-12-03 19:48	range	Relationship added	has duplicate 0002489
2007-12-04 00:23	jhughes@hughesjr.com	Note Added: 0006452
2007-12-04 00:48	smooge	Note Added: 0006453
2007-12-04 04:08	tdiehl	Issue Monitored: tdiehl
2007-12-04 08:10	ripienaar	Note Added: 0006456
2007-12-04 12:40	kbsingh@karan.org	Note Added: 0006469
2007-12-05 16:49	rayvd	Issue Monitored: rayvd
2007-12-05 20:33	sgao	Note Added: 0006485
2007-12-05 21:40	jhughes@hughesjr.com	Note Added: 0006486
2007-12-11 17:46	rayvd	Note Added: 0006542
2007-12-11 17:51	ripienaar	Note Added: 0006543
2007-12-11 18:06	rayvd	Note Added: 0006544
2007-12-11 22:25	kbsingh@karan.org	Note Added: 0006545
2007-12-12 04:49	dgoldsmith	Note Added: 0006549
2007-12-30 00:51	rayvd	Note Added: 0006620
2008-01-02 11:39	jhughes@hughesjr.com	Status	new => closed
2008-01-02 11:39	jhughes@hughesjr.com	Resolution	open => fixed
2008-02-01 10:28	range	Relationship added	has duplicate 0002643