On Tue, Oct 6, 2020, 6:14 PM Antal Nemeš <Antal.Nemes at hycu.com> wrote: > > > > -----Original Message----- > > From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Josh > > Boyer > > Sent: Tuesday, 6 October 2020 14:20 > > To: The CentOS developers mailing list. <centos-devel at centos.org> > > Subject: Re: [CentOS-devel] Module version differences between RHEL8 and > > Centos8? > > > > CAUTION: Origin is external! The content might not be safe! > > > > > > On Mon, Oct 5, 2020 at 7:10 PM Antal Nemeš <Antal.Nemes at hycu.com> > > wrote: > > > > > > > -----Original Message----- > > > > From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of > > > > Johnny Hughes > > > > Sent: Monday, 5 October 2020 16:53 > > > > To: centos-devel at centos.org > > > > Subject: Re: [CentOS-devel] Module version differences between RHEL8 > > > > and Centos8? > > > > > > > > > > > > > On 10/4/20 4:54 PM, Antal Nemeš wrote: > > > > > Is there any way to correlate modular package versions in RHEL8.x > > > > > with > > > > ones from Centos8.x in any way, no matter how difficult? > > > > > > > > > > For example, looking at package list for > > > > https://access.redhat.com/errata/RHSA-2020:3714: > > > > > - RedHat lists > > > > > httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.x86_64.rpm > > > > > - in CentOS this (probably?) matches > > > > > httpd-0:2.4.37-21.module_el8.2.0+494+1df74eae.x86_64 > > > > > > > > > > AFAIK, the non-modular packages shared the same NEVRA between > > RHEL > > > > and Centos (not sure if there were exceptions, though). > > > > > > > > > > > > > Modules are built by a new component called MBS (Module Build > > System) .. > > > > it works in conjunction with KOJI to do bulids. > > > > > > > > Because of MBS, exact module names are not possible between RHEL > > and > > > > CentOS. This is because 2 things in MBS are generated at build time. > > > > One is an index number .. one is a commit hash from git. > > > > > > > > Since git.centos.org is a closed system and it's hashes will be > > > > different than the internal RHEL git repo .. the hashes will never > match for > > commits. > > > > > > > > Also, since the CentOS MBS is a sperate system frmo the RHEL Build > > System .. > > > > the index number for build will also never be the same. > > > > > > > > Therefore, modules will never patch with exact names. > > > > > > > > > > Thanks, that explains a lot > > > > > > Doesn't the import of sources into git.centos.org represent state from > > internal RHEL repos that produced released RHEL packages? > > > > It represents the SRPMs that are in the released RHEL packages. > > > > > Does this import contain any kind of hash reference or any kind of > identifier > > from RHEL repo, such that it could be used to link RHEL released modules > > with Centos? > > > > It does not, because the source is pushed from SRPMs, not the internal > RHEL > > git repositories. > > Makes sense. But the names of src.rpm published by RHEL do contain index > and commit hash, don't they? > They contain part of one, yes. The SRPM is exploded though, and the Release version does not contain the hash as it calculated by MBS at build time, as Johnny said. It's part of dist. The import records the full NVR as a tag, but that has no bearing on the CentOS git hash or build system. E.g. from the link I referenced earlier at > https://access.redhat.com/errata/RHSA-2020:3714 , src.rpm is > httpd-2.4.37-21.module+el8.2.0+5008+cca404a3.src.rpm > Are these original src.rpm names lost during the import process? > No, but it doesn't matter as explained above. If you would like to ensure RHEL metadata is useful for the systems you maintain, I would suggest using RHEL. I realize that is not always feasible or desirable for some, but mapping that metadata to binaries built by another project is fairly outside the scope of what it is intended to cover. It would be false to assume the same analysis and metadata applied to binaries that the product teams don't have control over or even look at simply because the NVR matched. Build order, build systems, etc all matter. We make a point to be honest to our customers and to our community projects and only intend errata metadata to cover RHEL itself. Metadata about CentOS binaries should come from the CentOS project and systems using that OS should rely on that. josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201006/cca0b9b4/attachment-0006.html>