Hello Centos developers,
My company would like to use Red-Hat/Centos as a target system for releasing (proprietary) software.
In order to do this properly, I've constructed an infrastructure which allows to build those packages, wrapping mock and other tools. Such infrastructure uses a pool of Centos virtual machines for the building phase.
A question that keeps popping in my mailbox is how to build those packages without the 'centos' suffix, as in:
%{name}-%{version}.el7.centos.x86_64.rpm
Some developers here find that `.centos` tag quite disturbing as we are supposed to release for Red Hat.
I think the right thing to do here would be getting a (physical, licensed) Red Hat builder to do the job. But I'm not sure of what this would entail. For instance, is there a mock configuration to use for that? Would that be included in a Red Hat machine?
On 03/05/2018 12:44 PM, dacav wrote:
Hello Centos developers,
My company would like to use Red-Hat/Centos as a target system for releasing (proprietary) software.
In order to do this properly, I've constructed an infrastructure which allows to build those packages, wrapping mock and other tools. Such infrastructure uses a pool of Centos virtual machines for the building phase.
A question that keeps popping in my mailbox is how to build those packages without the 'centos' suffix, as in:
%{name}-%{version}.el7.centos.x86_64.rpmSome developers here find that `.centos` tag quite disturbing as we are supposed to release for Red Hat.
I think the right thing to do here would be getting a (physical, licensed) Red Hat builder to do the job. But I'm not sure of what this would entail. For instance, is there a mock configuration to use for that? Would that be included in a Red Hat machine?
You can override dist tag in your mock config:
config_opts['macros']['%dist'] = '.el7'
On 2018-03-05, Mikolaj Izdebski mizdebsk@redhat.com wrote:
config_opts['macros']['%dist'] = '.el7'
Thanks, Mikolaj and Leon, for your answers.
So this makes me wonder: what is the likelyhood of getting some error on RedHat without being able to detect it under CentOS?
Let's say that my system builds in CentOS with modified %dist and then straight ahead for testing on a RedHat machine. Is there any chance of a building error which would happen under RedHat (but not under CentOS), which would introduce some subtle bug under RedHat?
On Mon, Mar 5, 2018 at 4:13 AM, dacav dacav@teknik.io wrote:
On 2018-03-05, Mikolaj Izdebski mizdebsk@redhat.com wrote:
config_opts['macros']['%dist'] = '.el7'
Thanks, Mikolaj and Leon, for your answers.
So this makes me wonder: what is the likelyhood of getting some error on RedHat without being able to detect it under CentOS?
Let's say that my system builds in CentOS with modified %dist and then straight ahead for testing on a RedHat machine. Is there any chance of a building error which would happen under RedHat (but not under CentOS), which would introduce some subtle bug under RedHat?
That totally depends on your code. Is it checking to see if the package is running on a real RHEL box? If it is, how is it checking?
On 2018-03-05, Troy Dawson tdawson@redhat.com wrote:
Let's say that my system builds in CentOS with modified %dist and then straight ahead for testing on a RedHat machine. Is there any chance of a building error which would happen under RedHat (but not under CentOS), which would introduce some subtle bug under RedHat?
That totally depends on your code. Is it checking to see if the package is running on a real RHEL box? If it is, how is it checking?
Let's say it is (currently it is not, for shame). What I would do is to run a set of regression tests, to make sure that the software works.
OK, we are going hypothetical here: tell me if I'm saying something stupid. :) Also, not that I don't trust your answers about %dist, it's just a matter of curiosity.
Say there's a problem, maybe some obscure bug at compiler level or so. Let's say that the GCC version in RedHat fixed that bug. CentOS has not exactly the same version (and here's my little doubt: in theory it should be slightly behind, right?) In our scenario that bug is not fixed for CentOS but it is for RedHat.
I'm building under CentOS, not detecting the problem. I'm then testing under RedHat, not detecting the problem either (regression test has not a 100% coverage). The user gets to face a weird segfault.
Could something like this happen, due to a discrepancy of any kind, between the two distros?
On 06/03/18 12:04, dacav wrote:
Say there's a problem, maybe some obscure bug at compiler level or so. Let's say that the GCC version in RedHat fixed that bug. CentOS has not exactly the same version (and here's my little doubt: in theory it should be slightly behind, right?) In our scenario that bug is not fixed for CentOS but it is for RedHat.
In normal circumstances, CentOS repackages, rebuilds and releases upstream Redhat updates within hours. I don't remember there being a delay of more than a couple of days in most cases. The only time that this changes is at a new point release when it's necessary to wait for all of the hundreds of packages involved to be rebuilt and released at the same time. The procedure in this case is that they are all built and then the "CR" yum repository is populated with those updates and it's made available to all. The CR repo is disabled by default so it's an opt-in process to get those new updates at that time. Recent point releases have taken a few days to go from RHEL-release to CR availability, pretty sure always less than a week.
Once the iso images are built and tested, which usually takes another week or so for those to be released and it's only when that happens that the standard yum repos - base and updates - get the new point release packages and everyone gets the new packages.
Otherwise, if you find a CentOS package that doesn't behave exactly the same way as the RHEL equivalent package of the same version number then it's a bug and you should inform the team via a bugs.centos.org entry.
Trevor
On 2018-03-06, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
In normal circumstances, CentOS repackages, rebuilds and releases upstream Redhat updates within hours. [...] Otherwise, if you find a CentOS package that doesn't behave exactly the same way as the RHEL equivalent package of the same version number then it's a bug and you should inform the team via a bugs.centos.org entry.
Thank you! That was very informative.
Thank you all :)
Am 05.03.2018 um 12:44 schrieb dacav dacav@teknik.io:
Hello Centos developers,
My company would like to use Red-Hat/Centos as a target system for releasing (proprietary) software.
In order to do this properly, I've constructed an infrastructure which allows to build those packages, wrapping mock and other tools. Such infrastructure uses a pool of Centos virtual machines for the building phase.
A question that keeps popping in my mailbox is how to build those packages without the 'centos' suffix, as in:
%{name}-%{version}.el7.centos.x86_64.rpm
Some developers here find that `.centos` tag quite disturbing as we are supposed to release for Red Hat.
I think the right thing to do here would be getting a (physical, licensed) Red Hat builder to do the job. But I'm not sure of what this would entail. For instance, is there a mock configuration to use for that? Would that be included in a Red Hat machine?
The %{?dist} tag is up to you. Its part of the versioning.
-- LF
-
dacav -
Leon Fauster -
Mikolaj Izdebski -
Trevor Hemsley -
Troy Dawson