When it comes to CentOS Stream, should the ID_LIKE parameter be changed to properly designate the upstream nature of CentOS in regards to RHEL? As of now, both Stream 8 and 9 are using the classic CentOS identifier of "rhel fedora". If the change of being upstream is strict enough, CentOS should be changed to "fedora", and RHEL should be altered to "centos fedora". However, I've got a feeling a lot of scripts and tooling may be looking to see if "rhel" is in the ID_LIKE parameter, which may end up preventing installations of software on Stream for limited reasons. I don't have any examples or numbers to back that up, just a hunch on how people use the os-release (and redhat/centos-release) file.
Is this something that should be adjusted, or left as is for compatibility?
On Fri, Jul 9, 2021 at 12:27 PM Mike Rochefort mroche@redhat.com wrote:
When it comes to CentOS Stream, should the ID_LIKE parameter be changed to properly designate the upstream nature of CentOS in regards to RHEL? As of now, both Stream 8 and 9 are using the classic CentOS identifier of "rhel fedora". If the change of being upstream is strict enough, CentOS should be changed to "fedora", and RHEL should be altered to "centos fedora". However, I've got a feeling a lot of scripts and tooling may be looking to see if "rhel" is in the ID_LIKE parameter, which may end up preventing installations of software on Stream for limited reasons. I don't have any examples or numbers to back that up, just a hunch on how people use the os-release (and redhat/centos-release) file.
Is this something that should be adjusted, or left as is for compatibility?
We should leave it alone. It's still "centos" and it is effectively compatible with classic CentOS. I'd shudder at the number of things that would break if we changed ID.
On Fri, 9 Jul 2021 at 12:27, Mike Rochefort mroche@redhat.com wrote:
When it comes to CentOS Stream, should the ID_LIKE parameter be changed to properly designate the upstream nature of CentOS in regards to RHEL? As of now, both Stream 8 and 9 are using the classic CentOS identifier of "rhel fedora". If the change of being
Stream 8 is still downstream of RHEL so changing it would be wrong. Stream 9 is upstream of RHEL so it makes sense to change it there.
upstream is strict enough, CentOS should be changed to "fedora", and RHEL should be altered to "centos fedora". However, I've got a feeling a lot of scripts and tooling may be looking to see if "rhel" is in the ID_LIKE parameter, which may end up preventing installations of software on Stream for limited reasons. I don't have any examples or numbers to back that up, just a hunch on how people use the os-release (and redhat/centos-release) file.
Is this something that should be adjusted, or left as is for compatibility?
-- Mike Rochefort _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jul 9, 2021 at 12:36 PM Stephen John Smoogen smooge@gmail.com wrote:
Stream 8 is still downstream of RHEL so changing it would be wrong. Stream 9 is upstream of RHEL so it makes sense to change it there.
This is what I was trying to get at. I understand not wanting to touch Stream 8 considering its current situation (though this is potentially subject to change). I think this may be a valid change for Stream 9 considering it is yet unreleased in GA form. The docs on the matter are fairly straightforward, but leave some wiggle room which is why I brought this up.
man 5 os-release It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from. An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible. ... Operating systems should be listed in order of how closely the local operating system relates to the listed ones, starting with the closest.
It comes back to the idea of compatibility. Is any breakage from this something the community and package maintainers should have to deal with?
I am strongly against this. The field is called ID_LIKE, not ID_UPSTREAM. CentOS Stream is like RHEL. Based on koji builds, CS8 is currently 80% identical to CL8, and therefore approximately 80% the same as RHEL. To be clear, I'm not pulling this percentage out of thin air, I'm using the productmd python library [0] to get the numbers out of our compose metadata.
[0] https://github.com/release-engineering/productmd
On Fri, Jul 9, 2021 at 11:56 AM Mike Rochefort mroche@redhat.com wrote:
On Fri, Jul 9, 2021 at 12:36 PM Stephen John Smoogen smooge@gmail.com wrote:
Stream 8 is still downstream of RHEL so changing it would be wrong. Stream 9 is upstream of RHEL so it makes sense to change it there.
This is what I was trying to get at. I understand not wanting to touch Stream 8 considering its current situation (though this is potentially subject to change). I think this may be a valid change for Stream 9 considering it is yet unreleased in GA form. The docs on the matter are fairly straightforward, but leave some wiggle room which is why I brought this up.
man 5 os-release It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from. An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible. ... Operating systems should be listed in order of how closely the local operating system relates to the listed ones, starting with the closest.
It comes back to the idea of compatibility. Is any breakage from this something the community and package maintainers should have to deal with?
-- Mike Rochefort
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Jul 09, 2021 at 02:53:00PM -0500, Carl George wrote:
I am strongly against this. The field is called ID_LIKE, not ID_UPSTREAM. CentOS Stream is like RHEL. Based on koji builds, CS8 is currently 80% identical to CL8, and therefore approximately 80% the same as RHEL. To be clear, I'm not pulling this percentage out of thin air, I'm using the productmd python library [0] to get the numbers out of our compose metadata.
It's even more alike than "80%" implies, because that remaining 20% is just 'some metadata is different', not "this package is completely alien now".
On Fri, Jul 09, 2021 at 12:27:19PM -0400, Mike Rochefort wrote:
When it comes to CentOS Stream, should the ID_LIKE parameter be changed to properly designate the upstream nature of CentOS in regards to RHEL? As of now, both Stream 8 and 9 are using the classic CentOS identifier of "rhel fedora". If the change of being upstream is strict enough, CentOS should be changed to "fedora", and RHEL should be altered to "centos fedora". However, I've got a feeling a lot of scripts and tooling may be looking to see if "rhel" is in the ID_LIKE parameter, which may end up preventing installations of software on Stream for limited reasons. I don't have any examples or numbers to back that up, just a hunch on how people use the os-release (and redhat/centos-release) file.
Is this something that should be adjusted, or left as is for compatibility?
CentOS Stream is basically less than one minor version ahead of RHEL (except for when the corresponding RHEL does not exist yet, as for CS9).
I feel like dropping 'rhel' would break a lot of use cases unnecessarily. e.g. for the software targeting RHEL you mentioned, we want the vendors to be testing on Stream to be ready for the next EL minor releases anyway.
From my experience in EPEL, most of the time packages compiled for RHEL (which is what EPEL is) work fine in Stream anyway.
Best regards,
On Fri, Jul 9, 2021 at 5:58 PM Michel Alexandre Salim via CentOS-devel centos-devel@centos.org wrote:
CentOS Stream is basically less than one minor version ahead of RHEL (except for when the corresponding RHEL does not exist yet, as for CS9).
I feel like dropping 'rhel' would break a lot of use cases unnecessarily. e.g. for the software targeting RHEL you mentioned, we want the vendors to be testing on Stream to be ready for the next EL minor releases anyway.
Breakage caused by this was my main concern. I'm neutral on this either way, I just wanted to know what the broader consensus was in terms of how strictly to interpret "upstream".
From my experience in EPEL, most of the time packages compiled for RHEL (which is what EPEL is) work fine in Stream anyway.
I feel such a change would mostly impact proprietary tools. I've seen some weird checks that rely on /etc/<distro>-release or perform generic checks on the os-release file without really looking deeper. Which has been fine in the latter case because 'rhel' was provided under CentOS.
An example of the former came up in the forums regarding the Abaqus software by Dassault Systemes. It checks for a " 8." pattern in the redhat-release file during install to know which system it's on, which wouldn't apply to Stream. Obviously removing the "." would 'solve' this scenario, but it's still not a clean or portable method across distros.
On 7/9/21 6:06 PM, Mike Rochefort wrote:
On Fri, Jul 9, 2021 at 5:58 PM Michel Alexandre Salim via CentOS-devel centos-devel@centos.org wrote:
CentOS Stream is basically less than one minor version ahead of RHEL (except for when the corresponding RHEL does not exist yet, as for CS9).
I feel like dropping 'rhel' would break a lot of use cases unnecessarily. e.g. for the software targeting RHEL you mentioned, we want the vendors to be testing on Stream to be ready for the next EL minor releases anyway.
Breakage caused by this was my main concern. I'm neutral on this either way, I just wanted to know what the broader consensus was in terms of how strictly to interpret "upstream".
From my experience in EPEL, most of the time packages compiled for RHEL (which is what EPEL is) work fine in Stream anyway.
I feel such a change would mostly impact proprietary tools. I've seen some weird checks that rely on /etc/<distro>-release or perform generic checks on the os-release file without really looking deeper. Which has been fine in the latter case because 'rhel' was provided under CentOS.
An example of the former came up in the forums regarding the Abaqus software by Dassault Systemes. It checks for a " 8." pattern in the redhat-release file during install to know which system it's on, which wouldn't apply to Stream. Obviously removing the "." would 'solve' this scenario, but it's still not a clean or portable method across distros.
I think you want to make stream work so that when people are building for items for RHEL 9 .. it just works in stream as well. I am not sure what benefit we would see in changing it, compared to leaving it alone.
And for the record .. CentOS Stream is infinitely more like RHEL than Fedora.
-
Carl George -
Johnny Hughes -
Matthew Miller -
Michel Alexandre Salim -
Mike Rochefort -
Neal Gompa -
Stephen John Smoogen