CentOS - Apr 2015 - [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64

On 04/02/2015 04:43 PM, Phelps, Matthew wrote:
> On Thu, Apr 2, 2015 at 11:19 AM, Lamar Owen <lowen at pari.edu>
wrote:
> 
>> On 04/02/2015 10:59 AM, Phelps, Matthew wrote:
>>
>>> It's not just the name of the ISO file. c.f. the VERSION_ID
variable in
>>> /etc/os-release
>>>
>> In that particular place it is actually rather important, but that is
>> orthogonal to the ISO name.
>>
>>
> I agree, but this thread started off with a more general discussion of
> release/version numbering.
> 
os-release has been at /7/ since the first CentOS 7 release - what extra
value does having 7.1 in there bring ? At best it just says that your
centos-release rpm has not been updated and/or there is no system level
state change that required metadata in that file.

Note that any CentOS machine, updated to the same point in time,
regardless of where and how it was privisioned should give you the same
functional package set. This is an important thing.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc

On Thu, Apr 2, 2015 at 10:56 AM, Karanbir Singh <mail-lists at karan.org>
wrote:
>
> os-release has been at /7/ since the first CentOS 7 release - what extra
> value does having 7.1 in there bring ? At best it just says that your
> centos-release rpm has not been updated and/or there is no system level
> state change that required metadata in that file.
If you know that some feature was added or bug fixed in RH 7.1,  or
more relevant, your boss or security officer or application developer
knows that, there is very much value in being able to say that  CentOS
7.1-whatever includes the same features/fixes, and that your automated
inventory database will show which machines have been updated to that
version.   Otherwise you'll spend the rest of the day discussing how
fix x is done in package-revs-n1 fix y is in package-rev-n2 and how to
check for it.   Sometimes you need the latter detail, but mostly not,
especially for the application guys.
> Note that any CentOS machine, updated to the same point in time,
> regardless of where and how it was privisioned should give you the same
> functional package set. This is an important thing.
Yes, but how do you explain that relationship to someone who only has
a summary of the RH releases or where the Centos release stands
compared to it.  For example, what would you have said a few days ago?

-- 
   Les Mikesell
     lesmikesell at gmail.com

Le 02/04/2015 18:22, Les Mikesell a ?crit :
>> Note that any CentOS machine, updated to the same point in time,
>> >regardless of where and how it was privisioned should give you the
same
>> >functional package set. This is an important thing.
> Yes, but how do you explain that relationship to someone who only has
> a summary of the RH releases or where the Centos release stands
> compared to it.  For example, what would you have said a few days ago?
Notice that a new minor release includes new drivers for new servers, so 
it is important to know if you can install at all the system on your 
server, before any updates !

Alain

-- 
Administrateur Syst?me/R?seau
Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20)
Centre de Recherche Alcatel Data IV - Marcoussis
route de Nozay - 91460 Marcoussis
Tel : 01-69-63-61-34

On Thu, Apr 02, 2015 at 04:56:45PM +0100, Karanbir Singh
wrote:
> os-release has been at /7/ since the first CentOS 7 release - what extra
> value does having 7.1 in there bring ? At best it just says that your
Compatibility with RedHat, that says 7.1 ?

-- 

rgds
Stephen

On Thu, Apr 2, 2015 at 12:22 PM, Les Mikesell <lesmikesell at gmail.com>
wrote:
> On Thu, Apr 2, 2015 at 10:56 AM, Karanbir Singh <mail-lists at
karan.org>
> wrote:
> >
> > os-release has been at /7/ since the first CentOS 7 release - what
extra
> > value does having 7.1 in there bring ? At best it just says that your
> > centos-release rpm has not been updated and/or there is no system
level
> > state change that required metadata in that file.
>
> If you know that some feature was added or bug fixed in RH 7.1,  or
> more relevant, your boss or security officer or application developer
> knows that, there is very much value in being able to say that  CentOS
> 7.1-whatever includes the same features/fixes, and that your automated
> inventory database will show which machines have been updated to that
> version.   Otherwise you'll spend the rest of the day discussing how
> fix x is done in package-revs-n1 fix y is in package-rev-n2 and how to
> check for it.   Sometimes you need the latter detail, but mostly not,
> especially for the application guys.
>
>
This is the crux of the issue in my mind. The complete departure from the
upstream
naming conventions, weather they are "correct" or "relevant"
or not, is a
major change
and is becoming a major hassle, maybe not from an engineering point of
view, but from
a practical, day-to-day one.

Change is fine, but it requires work to deal with. And most of us don't
have time to deal
with major changes. This is a major change from past practice for CentOS,
and there are
many operational implications of it that apparently haven't been
considered.


-- 
Matt Phelps
System Administrator, Computation Facility
Harvard - Smithsonian Center for Astrophysics
mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu