Karanbir,
Can you look into closing out the bugs that can be closed etc?
Can also [1,2] be looked into to confirm package depends on abrt / report (hidden gotchas). Look at the example spec file at the changes that are required and the level of them that the Application Backend will have to support. Is there someone that can take on the App Server end?
Also needed to know if you are symlinking from "redhat-release" to "centos-release" or not. That depends on how other packages need to be patched, ie "lsb_release".
John
[1] http://bugs.centos.org/view.php?id=4648 [2] http://bugs.centos.org/view.php?id=4647
Hi John,
On 01/05/2011 11:40 AM, JohnS wrote:
Karanbir,
Can you look into closing out the bugs that can be closed etc?
Yes, I will try and get to that either today or early in the day tomorrow.
Can also [1,2] be looked into to confirm package depends on abrt / report (hidden gotchas). Look at the example spec file at the changes that are required and the level of them that the Application Backend will have to support. Is there someone that can take on the App Server end?
Also needed to know if you are symlinking from "redhat-release" to "centos-release" or not. That depends on how other packages need to be patched, ie "lsb_release".
I am keen on looking at using a centos-release with a link over from redhat-release, but lets consider / look at the implications and fallouts before deciding on something for sure. There should not be any reason to patch redhat-lsb; whatever we do should not, ideally, have any impact on code and expectations from other apps ( specially since there might be implications to third party apps that we cant / dont want to have a feedback loop into )
What do you see as needing patched into redhat_lsb, that would fallout from the to-symlink or not-to-symlink decision ?
[1] http://bugs.centos.org/view.php?id=4648 [2] http://bugs.centos.org/view.php?id=4647
On Wed, Jan 05, 2011 at 11:42:00AM +0000, Karanbir Singh wrote:
I am keen on looking at using a centos-release with a link over from redhat-release, but lets consider / look at the implications and fallouts before deciding on something for sure. There should not be any reason to patch redhat-lsb; whatever we do should not, ideally, have any impact on code and expectations from other apps ( specially since there might be implications to third party apps that we cant / dont want to have a feedback loop into )
Third-party proprietary programs which look for /etc/redhat-release are often (already in CentOS 5) confused by finding something other than an exact Red Hat version string there. There's really nothing we can do about that, although having separate files allows /etc/centos-release to contain the real information while local admins can edit /etc/redhat-release to have whatever e.g. Oracle is looking for.
Of course, this can be done whether or not the file is originally a symlink.
On 01/05/2011 04:29 PM, Matthew Miller wrote:
Third-party proprietary programs which look for /etc/redhat-release are often (already in CentOS 5) confused by finding something other than an exact Red Hat version string there. There's really nothing we can do about that, although having separate files allows /etc/centos-release to contain the real information while local admins can edit /etc/redhat-release to have whatever e.g. Oracle is looking for.
Sounds good to me, lets go with the symlink unless anyone comes up with a reason not to ( and if so, please file at : #4593 )
- KB
On Wed, 2011-01-05 at 21:21 +0000, Karanbir Singh wrote:
On 01/05/2011 04:29 PM, Matthew Miller wrote:
Third-party proprietary programs which look for /etc/redhat-release are often (already in CentOS 5) confused by finding something other than an exact Red Hat version string there. There's really nothing we can do about that, although having separate files allows /etc/centos-release to contain the real information while local admins can edit /etc/redhat-release to have whatever e.g. Oracle is looking for.
Sounds good to me, lets go with the symlink unless anyone comes up with a reason not to ( and if so, please file at : #4593 )
Noted there
John / em2
On Wed, Jan 5, 2011 at 11:29 AM, Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jan 05, 2011 at 11:42:00AM +0000, Karanbir Singh wrote:
I am keen on looking at using a centos-release with a link over from redhat-release, but lets consider / look at the implications and fallouts before deciding on something for sure. There should not be any reason to patch redhat-lsb; whatever we do should not, ideally, have any impact on code and expectations from other apps ( specially since there might be implications to third party apps that we cant / dont want to have a feedback loop into )
Third-party proprietary programs which look for /etc/redhat-release are often (already in CentOS 5) confused by finding something other than an exact Red Hat version string there. There's really nothing we can do about that, although having separate files allows /etc/centos-release to contain the real information while local admins can edit /etc/redhat-release to have whatever e.g. Oracle is looking for.
Yeah, I've been tweaking such tools to do 'cat /etc/redhat-release | awk '{print $(NF-2}'` to get the major release number, instead of the more common "print the sixth element commands.
On Wed, 2011-01-05 at 11:29 -0500, Matthew Miller wrote:
On Wed, Jan 05, 2011 at 11:42:00AM +0000, Karanbir Singh wrote:
I am keen on looking at using a centos-release with a link over from redhat-release, but lets consider / look at the implications and fallouts before deciding on something for sure. There should not be any reason to patch redhat-lsb; whatever we do should not, ideally, have any impact on code and expectations from other apps ( specially since there might be implications to third party apps that we cant / dont want to have a feedback loop into )
Third-party proprietary programs which look for /etc/redhat-release are often (already in CentOS 5) confused by finding something other than an exact Red Hat version string there. There's really nothing we can do about that, although having separate files allows /etc/centos-release to contain the real information while local admins can edit /etc/redhat-release to have whatever e.g. Oracle is looking for.
Of course, this can be done whether or not the file is originally a symlink.
Noted...
John / em2
-
JohnS -
Karanbir Singh -
Matthew Miller -
Nico Kadel-Garcia