On Fri, Aug 20, 2021, 5:16 PM Neal Gompa <ngompa13 at gmail.com> wrote: > On Fri, Aug 20, 2021 at 4:09 PM Josh Boyer <jwboyer at redhat.com> wrote: > > > > On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa <ngompa13 at gmail.com> wrote: > > > > > > On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer <jwboyer at redhat.com> wrote: > > > > > > > > On Fri, Aug 20, 2021 at 1:37 PM Carl George <carl at redhat.com> wrote: > > > > > > > > > > On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa <ngompa13 at gmail.com> > 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 > > > > > > > > > > Not exactly. Sometimes RHEL maintainers add digits after %dist, > which > > > > > results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's > > > > > not impossible to parse, but it's much more complicated that just > > > > > ignoring everything after ".module". > > > > > > > > > > > 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. > > > > > > > > > > I'm not aware of any policy against allowing this in the project. > If > > > > > there is I hope board members will speak up and clarify that. I > > > > > suspect it's more of a resource thing than anything. > > > > > > > > I think lack of awareness of a publicly documented policy against > > > > allowing this in the project is likely true, but also irrelevant. We > > > > don't have a policy against allowing a FreeBSD kernel or using > > > > Ubuntu's version of gcc, yet we wouldn't do those. In the absence of > > > > meticulously detailed bylaws, we have historical precedent setting > > > > defacto policy. I don't expect this to change. > > > > > > > > That being said, an update metadata mechanism for CentOS Stream is > > > > certainly hampered by resource constraints both in terms of tooling > > > > and in terms of the impact on the people developing the OS through > the > > > > CentOS Stream project. For a continuously developed and continuously > > > > delivered OS, we expect a large amount of churn on a day to day > basis. > > > > Updates are a regular occurence, and they're important either because > > > > of fixes or because of new features. Changes are documented in MRs, > > > > RPM changelogs, and referenced bugs for those interested. > > > > > > > > > > It's always been possible to have updateinfo generated as build > > > submissions go through. That's literally how it's done in Fedora with > > > Bodhi. > > > > > > It's not that much of a stretch to say "deploy Bodhi, make voting > > > advisory or turn it off, and have builds submitted through it with the > > > right information and auto-release based on gating checks". That > > > structured data can be pulled in and used for Red Hat update > > > advisories internally too, which simplifies the pipeline to validate > > > and release updates. Or if you have a beef against Bodhi, then why not > > > use the tooling Scientific Linux created to make updateinfo? Troy and > > > Pat are very familiar with it, and it's publicly available: > > > https://pagure.io/python-Updateinfo > > > > > > Okay, let's say we can't do it for CentOS Stream 8 because of resource > > > constraints. Well then, what about CentOS Stream 9, where the RHEL > > > developers themselves are submitting the builds? There's no logical > > > resourcing problem there. Deploy Bodhi for update submissions and tie > > > > You have clearly never worked on making a change to a RHEL package :). > > I will promise you that there are already a significant number of > > steps that developers must do to even get to the point where they can > > file an MR. Putting more process and tooling and hurdles in their way > > before the code even gets into RHEL is absolutely a resource problem > > and I am not going to sign them up to do that. If anything, we're > > trying to simplify even though many will tell you it doesn't look like > > that. > > > > I know you meant that with good intention, but it's easy to read it as > > "there's no resourcing problem because someone else has to do the > > work." > > > > I certainly have made changes to RHEL packages. My name exists in > changelogs and commits in enough packages in RHEL and CentOS Stream > that I think that would be an unfair characterization. :) > I'm aware of most of the steps for making package changes in RHEL, and > I already am aware that packagers for RHEL have to go through the > effort of declaring what an update is, what it's for, and whether it > requires relogin/reboot to fully apply. These are the core properties > that are defined in updateinfo. Defining them to push a build in > CentOS Stream is something that I don't think is an unreasonable ask. > It's the same thing we ask community folks in Fedora to do, after all. > We don't ask the Fedora community to do it twice through two different tools though. Again, I'm not adding more process to an already arduous process. Also, it's a case of frequency as well. An errata in RHEL has to be finalized officially once before it's released. Some maintainers do it multiple times as they go, but many do not. Bugs attached, notes updated, etc need to be completed before GA, every 6 months. Your proposal would require them to do this for every build. That's expensive. > > the gating into the auto-release criteria. The Fedora CI folks were > > > already doing that for Fedora Rawhide, so it's no stretch to have it > > > for CentOS Stream too. > > > > > > The idea is not new: I've talked to the CentOS project folks about it > > > many times in the past. They get *extremely* uncomfortable and tell me > > > that they can't do it for various reasons even though they want to. > > > It's one of the biggest complaints everyone has about the project. > > > It's made worse by the fact that none of the ecosystem tooling for > > > updates works in any useful manner without updateinfo. RPM changelogs > > > are no substitute because no automation works with that. You know that > > > as well as everyone else here. > > > > Producing that information isn't only about tooling, and the fact that > > people would immediately rely on it for automation makes it difficult > > to suggest anyone else doing it on the side is a viable solution. If > > it's wrong, that has bad consequences. I'd certainly be against it > > under the project umbrella if it wasn't part of the official delivery > > anyway. > > > > I still question the utility of it though. It's a continuous delivery > > model. You have to update. Want to know if you have all available > > bug fixes? Update. If your bug isn't fixed, it doesn't change the > > fact that you have all *available* bug fixes. There are no batches or > > releases. It's called Stream for a reason. > > > > That doesn't mean I shouldn't have the ability to configure > dnf-automatic to apply all updates automatically that don't require > relogin and reboot and then have it email me to notify me for updates > that *do* require that so I can schedule time to actually go and apply > it. The list that sets needs reboot via errata is literally hard coded to a few packages, and we have other tools being introduced that will actually measure this via runtime heuristics via dnf plugins. I'm happy to just give you the list, (kernel, glibc, systemd, maybe one or two others) and you're welcome to use the improved tools already in the distro. josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210820/b4600707/attachment-0005.html>