[CentOS-devel] Is there any way to follow errata for Stream 8?

Fri Aug 20 16:55:33 UTC 2021
Johnny Hughes <johnny at centos.org>

On 8/20/21 11:34 AM, Neal Gompa wrote:
> On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes <johnny at centos.org> wrote:
>>
>> On 8/19/21 11:21 PM, John R. Dennison wrote:
>>> On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
>>>> Even emails like I see for for CentOS 7 would be ok.
>>>
>>> Considering that people have had nearly 2 years to get such notices out
>>> for 8 and it's still not happened I wouldn't hold my breath if I were
>>> you.
>>>
>>
>> I would provide the information if i could, it is not easy to do because
>> of modularity.
>>
>> The thing that builds el8 modules is called MBS .. if you look at MBS
>> operations, one of the things that gets generated as part of the
>> filename.  Here is an example:
>>
>> https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
>>
>> Part of the file name is dynamic, created by MBS at build time.  For
>> example, one of the Source RPM filenames generated is:
>>
>> runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
>>
>> That is not it's filename in RHEL8.  In RHEL 8 .. the filename is:
>>
>> runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
>>
>> There is no easy way to figure out the file names that match up between
>> the two systems.  I took me 15 minutes to figure out that one filename,
>> this does not scale.
> 
> Everything prior to ".module" should be unique, identifiable, and
> identical between RHEL and CentOS. MBS whacks %dist to add MBS
> information at the end. So there is some mapping. Additionally, when
> the RPMs are imported from RHEL into CentOS, the original NVR is
> present as a tag. Ignoring transmodrifier remapping modulemd commits
> between RHEL and CentOS, you have enough baseline references to be
> able to connect the dots because the RHEL dist-git shorthash is
> present in the import tag, which would exist in the imported modulemd
> before transmodification.
> 
> That process could be automated, but I was never particularly
> motivated to do it because of the historical attitude around providing
> errata for CentOS users like Fedora users get.
> 
> 
The problem is that theoretically .. the same ENV could be in more than
one module. That would make this problematic for items that might the
same ENV and possibly a different release.

You would also need something that queried several git modulemd items
and did compares, etc.

And now that is a moot point as we are at about 3 months left in the
CentOS Linux 8 lifetime.  And these things are not at all relevant for
most of stream.