hi,
We have spent a lot of time working out how best to work the /etc/centos-release file in order to satisfy most use cases. We've had a lot of positive feedback on the three digit release numbering that went into the first CentOS-7 release. And in the coming months, as the rolling builds onramp we will start seeing movement around those. This will also help address some points learned from the community during the 7.0.1406 cycle.
We have also decided to split the /etc/redhat-release link to /etc/centos-release and use that as a way to better indicate what codebase the running CentOS Linux instance was derived from.
Examples of what these files will look like in say March 2015 ( if .1 is released upstream by then ):
------------------- /etc/centos-release: CentOS Linux release 7.1.1503 (Core)
/etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source)
-------------------
The /etc/os-release file remains unchaged to indicate CentOS-7 as being the distro being consumed. We will however, be adding ABRT specific content to the os-release file once we have bugs.centos.org setup to accept abrt requests - and we have the required patched rolled out into the distro. These additions will have no impact on numbering reported via tools that consume /etc/os-release.
The /etc/centos-release file will then evolve with every monthly release, with the updated file being pushed into updates repo. This implies if someone was to install from the March rolling build, their /etc/centos-release will already have 7.1.1503 and anyone having a previously installed machine, doing a yum update would see the same file drop in.
The net result is an impact for new people installing from rolling build media ( and instance media like live images, cloud images, containers etc ). One installed or running, there is no change to how CentOS Linux has been in the past. You just get regular updates, and any machine, regardless of how it was installed and when, updated to the same point in time will have identical content.
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
Le 23/02/2015 00:19, Karanbir Singh a écrit :
hi,
We have spent a lot of time working out how best to work the /etc/centos-release file in order to satisfy most use cases. We've had a lot of positive feedback on the three digit release numbering that went into the first CentOS-7 release. And in the coming months, as the rolling builds onramp we will start seeing movement around those. This will also help address some points learned from the community during the 7.0.1406 cycle.
We have also decided to split the /etc/redhat-release link to /etc/centos-release and use that as a way to better indicate what codebase the running CentOS Linux instance was derived from.
I'm aware of some inventory software (OCSinventory, FusionInventory) which rely on redhat-release to be a regular file (not a link) to detect real "RHEL" [1], and check some other files (centos-release, ...) for the clones.
Of course information from "lsb_release" is usually more accurate.
I have forward your mail to upstream dev of those projects.
Remi.
[1] http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/trunk/...
Examples of what these files will look like in say March 2015 ( if .1 is released upstream by then ):
/etc/centos-release: CentOS Linux release 7.1.1503 (Core)
/etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source)
The /etc/os-release file remains unchaged to indicate CentOS-7 as being the distro being consumed. We will however, be adding ABRT specific content to the os-release file once we have bugs.centos.org setup to accept abrt requests - and we have the required patched rolled out into the distro. These additions will have no impact on numbering reported via tools that consume /etc/os-release.
The /etc/centos-release file will then evolve with every monthly release, with the updated file being pushed into updates repo. This implies if someone was to install from the March rolling build, their /etc/centos-release will already have 7.1.1503 and anyone having a previously installed machine, doing a yum update would see the same file drop in.
The net result is an impact for new people installing from rolling build media ( and instance media like live images, cloud images, containers etc ). One installed or running, there is no change to how CentOS Linux has been in the past. You just get regular updates, and any machine, regardless of how it was installed and when, updated to the same point in time will have identical content.
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 22/02/2015 23:19, Karanbir Singh wrote:
/etc/centos-release: CentOS Linux release 7.1.1503 (Core)
/etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source)
Yay, thread necromancy.
This change is causing some surprise, because (as least some) config management tools are mis-identifying centos 7. What problem did it solve?
On 31 March 2015 at 14:09, Howard Johnson merlin@mwob.org.uk wrote:
On 22/02/2015 23:19, Karanbir Singh wrote:
/etc/centos-release: CentOS Linux release 7.1.1503 (Core)
/etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source)
Yay, thread necromancy.
This change is causing some surprise, because (as least some) config management tools are mis-identifying centos 7. What problem did it solve?
What tools are broken?
-- HJ
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 03/31/2015 11:15 PM, Stephen John Smoogen wrote:
On 31 March 2015 at 14:09, Howard Johnson <merlin@mwob.org.uk mailto:merlin@mwob.org.uk> wrote:
On 22/02/2015 23:19, Karanbir Singh wrote: /etc/centos-release: CentOS Linux release 7.1.1503 (Core) /etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source) Yay, thread necromancy. This change is causing some surprise, because (as least some) config management tools are mis-identifying centos 7. What problem did it solve?What tools are broken?
live quotes from #centos: <MerlinTHP> duritong: what is facter identifying 7.1 as? <duritong> MerlinTHP: RedHat <duritong> but it isn't able to figure out the release version
On 31/03/2015 21:18, Manuel Wolfshant wrote:
On 03/31/2015 11:15 PM, Stephen John Smoogen wrote:
On 31 March 2015 at 14:09, Howard Johnson <merlin@mwob.org.uk mailto:merlin@mwob.org.uk> wrote:
On 22/02/2015 23:19, Karanbir Singh wrote: /etc/centos-release: CentOS Linux release 7.1.1503 (Core) /etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source) Yay, thread necromancy. This change is causing some surprise, because (as least some) config management tools are mis-identifying centos 7. What problem did it solve?What tools are broken?
live quotes from #centos: <MerlinTHP> duritong: what is facter identifying 7.1 as? <duritong> MerlinTHP: RedHat <duritong> but it isn't able to figure out the release version
Yeah, looking at the facter sources, there's this bit of code:
https://github.com/puppetlabs/facter/blob/master/lib/src/facts/linux/operati...
It's only looking at /etc/redhat-release, and it's looking for various strings in that file to work out what OS it is. As the C7.1 redhat-release says "Red Hat" in it, it's identifying the OS as Red Hat.
I'm going to poke 7.1 with a few more tools and see what they say.
On 31/03/2015 21:27, Howard Johnson wrote:
live quotes from #centos:
<MerlinTHP> duritong: what is facter identifying 7.1 as? <duritong> MerlinTHP: RedHat <duritong> but it isn't able to figure out the release version
Yeah, looking at the facter sources, there's this bit of code:
https://github.com/puppetlabs/facter/blob/master/lib/src/facts/linux/operati...
It's only looking at /etc/redhat-release, and it's looking for various strings in that file to work out what OS it is. As the C7.1 redhat-release says "Red Hat" in it, it's identifying the OS as Red Hat.
I'm going to poke 7.1 with a few more tools and see what they say.
It also broke Ansible:
[root@c7dev2 ~]# rpm -q centos-release centos-release-7-0.1406.el7.centos.2.5.x86_64 [root@c7dev2 ~]# ansible 127.0.0.1 -m setup -a filter=ansible_distribution 127.0.0.1 | success >> { "ansible_facts": { "ansible_distribution": "CentOS" }, "changed": false }
[root@c7dev ~]# rpm -q centos-release centos-release-7-1.1503.el7.centos.2.7.x86_64 [root@c7dev ~]# ansible 127.0.0.1 -m setup -a filter=ansible_distribution 127.0.0.1 | success >> { "ansible_facts": { "ansible_distribution": "RedHat" }, "changed": false }
And it's broken ohai, so Chef is broken:
[root@c7dev2 ~]# ohai | fgrep platform "platform": "centos", "platform_version": "7.0.1406", "platform_family": "rhel", "platform": "x86_64-linux",
[root@c7dev ~]# ohai | fgrep platform "platform": "derived", "platform_version": null, "platform": "x86_64-linux",
So, does anyone know what this centos-release change fixes?
On 31/03/15 21:09, Howard Johnson wrote:
On 22/02/2015 23:19, Karanbir Singh wrote:
/etc/centos-release: CentOS Linux release 7.1.1503 (Core)
/etc/redhat-release Derived from Red Hat Enterprise Linux 7.1 (Source)
Yay, thread necromancy.
This change is causing some surprise, because (as least some) config management tools are mis-identifying centos 7. What problem did it solve?
what tools are these / can we reach out and help them get the right content ?
this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up.
At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
On 03/31/2015 10:00 PM, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
we are trying to thrash out a possible solution here. stand by
On 03/31/2015 10:33 PM, Karanbir Singh wrote:
On 03/31/2015 10:00 PM, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
we are trying to thrash out a possible solution here. stand by
ok so we are issuing a new centos-release file as an update and a base replacement that will resolve this issue - and we are also investigating redoing the isos in a way that we can solve this problem for people doing fresh installs.
stand by for more details
On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote:
On 03/31/2015 10:33 PM, Karanbir Singh wrote:
On 03/31/2015 10:00 PM, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
we are trying to thrash out a possible solution here. stand by
ok so we are issuing a new centos-release file as an update and a base replacement that will resolve this issue - and we are also investigating redoing the isos in a way that we can solve this problem for people doing fresh installs.
stand by for more details
Thanks for the update coming in, /etc/redhat-release is really an important file to get right...
Seems also the ISO images are refreshed with this.
best regards,
Florian La Roche
On 4/1/15 8:11 AM, Florian La Roche wrote:
On Tue, Mar 31, 2015 at 11:52:52PM +0100, Karanbir Singh wrote:
we are trying to thrash out a possible solution here. stand by
ok so we are issuing a new centos-release file as an update and a base replacement that will resolve this issue - and we are also investigating redoing the isos in a way that we can solve this problem for people doing fresh installs.
stand by for more details
Thanks for the update coming in, /etc/redhat-release is really an important file to get right...
Seems also the ISO images are refreshed with this.
best regards,
Florian La Roche
Team,
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
Karanbir Singh wrote:
another less-than-optimal solution would be for app developers to start using lsb_release to find out what distro and release they are installing onto. of course, that's a different problem, in more than one way, at least one of which is that lsb_release is not installed by default.
I'm switching the app installer for the program I maintain (at work) to use lsb_release just because it's so much easier than groping /etc/redhat-release.
have you looked at /etc/os-release ? you can just source it and you get the content needed. I believe most people are trying to drive towards using that ( plus you dont need the lsb dep chain under it then )
Bryan Seitz wrote:
Team,
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then.
* http://0pointer.de/blog/projects/os-release.html
Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier.
I don't think it's possible to change all redhat-release usage anyway.
--anders
On 04/02/2015 08:28 PM, Anders F Björklund wrote:
Bryan Seitz wrote:
Team,
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
But os-release is a systemd "feature"*. Seems unlikely to make it ?
Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6.
I don't think it's possible to change all redhat-release usage anyway.
Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints.
Peter
Peter wrote:
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
But os-release is a systemd "feature"*. Seems unlikely to make it ?
Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6.
Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ?
Most downstream usage of the distro/release is plain wrong*, anyway...
* easier to check a name/version, than to bother with packages and so-files and programs and other dependencies... just hope they don't rebase anything.
Go ahead and use the silly name of the distro file. I'm sure I'll survive :-)
I don't think it's possible to change all redhat-release usage anyway.
Well, fortunately it's not redhat-release, that's a package that comes with RHEL. CentOS comes with the package centos-release which is specific to CentOS and therefore we should be able to make changes to without worrying about upstream constraints.
Actually I think there was an effort to rename it as /etc/system-release, but not sure it caught on ? The "traditional" was always redhat-release...
And sure, centos-release is specific to CentOS just as fedora-release is specific to Fedora. But ignoring upstream/legacy constraints seems wrong ?
i.e. /etc/redhat-release is a symlink to it, so the syntax does matter.
But it seems that /etc/centos-release-upstream will provide the new info. Hopefully that (and your os-release) will be enough to make everyone happy.
And for the OS rant earlier, I suppose there's always uname(1) and arch(1).
--anders
On Thu, Apr 2, 2015 at 6:49 AM, Anders F Björklund afb@users.sourceforge.net wrote:
Peter wrote:
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
But os-release is a systemd "feature"*. Seems unlikely to make it ?
Really? On my system it's a very simple text file included with the centos-release package. I honestly can't see how having sys-v-init or upstart would make it impossible or even remotely difficult to create such a text file and include it in CentOS 5 and 6.
Sure, and as such it's probably "better" than the lsb_release *program*. But you would still have to install something extra, in the old releases ?
And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this:
On Thu, Apr 2, 2015 at 6:51 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
And in *all* the old management tools that need to detect the operating system, even the obsolete releases.Please don't muck with stable workflow: And for the inevitable XKCD cartoon about this:
https://xkcd.com/1172/
Sigh... This is why we can't have nice things. I've always thought that computer scientists and engineers could all have had great careers as legislators and lawers because they never do the simple, understandable thing and instead always have a million variations of what you are looking for bundled inside of even more irrelevant stuff. So instead of a standard one-line file installed without the heavyweight lsb packaged stuff or an even more sensible option to uname where you'd expect it, we need stuff like this code from OCSinventory just to identify the distribution. http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable... (and that's just for Linux - back up to the OS level for other unix-like flavors and there's a whole different agent for windows).
Anyway, zooming in to: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/stable... (a whole file/module just dedicated to finding the version on a Centos system, and it doesn't work) We see that it won't work on CentOS 7 because it's not expecting a symlink (lines 7 and 8). So it fails and falls through to the method that requires the lsb package to be installed - and just reports 'Linux' if that fails too.
Why does something this simple have to waste so much time?
On 04/02/2015 11:27 AM, Les Mikesell wrote:
Why does something this simple [as figuring out what OS and version you're on] have to waste so much time?
Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs.
It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem.
On Thu, Apr 2, 2015 at 10:34 AM, Lamar Owen lowen@pari.edu wrote:
On 04/02/2015 11:27 AM, Les Mikesell wrote:
Why does something this simple [as figuring out what OS and version you're on] have to waste so much time?
Sorry for the editorial brackets there, Les, but that is, I think, an accurate distillation of the previous paragraphs.
It's not simple because of the Perl mantra and the very nature of free and open source development. It is the beast we have; and as long as consensus between disparate distributions of just Linux is not found on this topic it will remain less simple than it could be. Distributions have vested interests - competitive, egotistic, and other - to do things differently, and that's not likely to change, as much as I wish it would. And that's just within the Linux ecosystem.
I understand the reason that distributions want to add exclusive extensions that, if you use them, make it impossible to ever use anything else. But, I'm not interested in making that kind of commitment. Seems worse than being married. So, please - stick to standards...
On Thu, Apr 2, 2015 at 11:59 AM, Les Mikesell lesmikesell@gmail.com wrote:
So, please - stick to standards...
The wonderful thing about standards is that there are so many of them to choose from.
On 4/2/15 3:28 AM, Anders F Björklund wrote:
Karanbir Singh wrote:
another less-than-optimal solution would be for app developers to start using lsb_release to find out what distro and release they are installing onto. of course, that's a different problem, in more than one way, at least one of which is that lsb_release is not installed by default.
I'm switching the app installer for the program I maintain (at work) to use lsb_release just because it's so much easier than groping /etc/redhat-release.
have you looked at /etc/os-release ? you can just source it and you get the content needed. I believe most people are trying to drive towards using that ( plus you dont need the lsb dep chain under it then )
Bryan Seitz wrote:
Team,
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then.
Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier.
I don't think it's possible to change all redhat-release usage anyway.
Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works.
I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward.
Bryan Seitz wrote:
I would love to see /etc/os-release added to CentOS5 and CentOS6 as well. Keep up the good work!
But os-release is a systemd "feature"*. Seems unlikely to make it ? Might as well use `/usr/bin/lsb_release` (and redhat-lsb-core) then.
Ironically it doesn't even contain the name of the Operating System... We saw this when it was introduced in (and broke) PackageKit earlier.
I don't think it's possible to change all redhat-release usage anyway.
Even redhat-lsb-core installs an insane amount of garbage just to get that one function we want. Other distributions (At least Debian/Ubuntu) already use /etc/os-release and there is no reason it cannot be populated by the centos-release package on C5/C6 as well. It is a good idea, the file has useful and standard contents, and it just works.
I am not advocating doing away with the legacy files, but this solution just makes sense and is the right thing to do moving forward.
I suppose there's nothing wrong with having *both* of them around. As long as it doesn't replace/delete the original files, that is...
It does address my concerns (for redhat-release) in that article, too. :-)
Seems like the mandated /usr/lib/os-release is missing from centos-release ? Supposedly /etc/os-release should be a relative symlink, for "compatibility".
Says http://www.freedesktop.org/software/systemd/man/os-release.html
But you would still need to parse "some other file" to get the minor version.
Since systemd only includes the "operating system version", i.e. 5 or 6 or 7
NAME="CentOS" VERSION="6 (Final)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="6" PRETTY_NAME="CentOS 6 (Final)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:6" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/"
So that old redhat-release would still be "needed", for getting at the 6.6...
--anders
On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote:
On 03/31/2015 10:00 PM, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
another less-than-optimal solution would be for app developers to start using lsb_release to find out what distro and release they are installing onto. of course, that's a different problem, in more than one way, at least one of which is that lsb_release is not installed by default.
I'm switching the app installer for the program I maintain (at work) to use lsb_release just because it's so much easier than groping /etc/redhat-release.
On 01/04/15 00:39, Fred Smith wrote:
On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote:
On 03/31/2015 10:00 PM, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
another less-than-optimal solution would be for app developers to start using lsb_release to find out what distro and release they are installing onto. of course, that's a different problem, in more than one way, at least one of which is that lsb_release is not installed by default.
I'm switching the app installer for the program I maintain (at work) to use lsb_release just because it's so much easier than groping /etc/redhat-release.
have you looked at /etc/os-release ? you can just source it and you get the content needed. I believe most people are trying to drive towards using that ( plus you dont need the lsb dep chain under it then )
On Tue, Mar 31, 2015 at 7:44 PM, Karanbir Singh mail-lists@karan.org wrote:
On 01/04/15 00:39, Fred Smith wrote:
On Tue, Mar 31, 2015 at 10:33:37PM +0100, Karanbir Singh wrote:
On 03/31/2015 10:00 PM, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
another less-than-optimal solution would be for app developers to start using lsb_release to find out what distro and release they are installing onto. of course, that's a different problem, in more than one way, at least one of which is that lsb_release is not installed by default.
I'm switching the app installer for the program I maintain (at work) to use lsb_release just because it's so much easier than groping /etc/redhat-release.
have you looked at /etc/os-release ? you can just source it and you get the content needed. I believe most people are trying to drive towards using that ( plus you dont need the lsb dep chain under it then )
I'm sorry, but I'm starring at http://vault.centos.org/3.1/i386/RedHat/RPMS/centos-release-3.1-1.i386.rpm. That primary configuration file reference of /etc/redhat-release dates back at least to 2004, and I'm quite confused by why anyone wanted to change it.
Mind you, *Fedora* is getting silly about things upsream When they used both Unicode and bash syntatically relevant punction in the ine release name for Fedora 19, which was "Schrödinger's Cat", it broke even more tools.
Nico Kadel-Garcia nkadel@gmail.com
On 31/03/15 22:00, Howard Johnson wrote:
On 31/03/2015 21:53, Karanbir Singh wrote:
what tools are these / can we reach out and help them get the right content ? this solves the problem of establishing an upstream, giving people who only need a lose knit baseline match and also giving people the centos-7 release stream that we've been building up. At the time of 7 1406 release, this was flagged up as the biggest issue that we need to fix from the distro side of things.
Hmm, ok. Can we put that data somewhere else instead (an /etc/redhat-upstream-release file or something) and revert the redhat-release change? We can't expect everyone to run around updating their system management tools for a change in a minor point release :(
http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html
update pushed.
sorry for breaking stuff folks :(
On 01/04/2015 03:41, Karanbir Singh wrote:
http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html
update pushed.
sorry for breaking stuff folks :(
Cheers for the speedy and comprehensive response, KB :)
-
Anders F Björklund -
Bryan Seitz -
Florian La Roche -
Fred Smith -
Howard Johnson -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Manuel Wolfshant -
Nico Kadel-Garcia -
Peter -
Remi Collet -
Stephen John Smoogen -
Tom Sorensen