One solution could be to rearchitect the way errata is released all together. Queue the errata for delivery to the list and also process the data into the update info simultaneously. Giving a single pane of glass to deal with for distributing errata. > On Sep 15, 2014, at 5:34 PM, Kevin Stange <kevin at steadfast.net> wrote: > >> On 09/15/2014 11:55 AM, Karanbir Singh wrote: >> Hi >> >>> On 09/15/2014 05:51 PM, Steven Crothers wrote: >>> Sorry KB, I thought it was obvious from Fedora (but I forget not all >>> CentOS users are Fedora users and vice versa). >>> >>> "errata in the repo" means this: >>> http://mirror.steadfast.net/epel/7/x86_64/repodata/673013755b70ab1c50a53bae58d36a2321005e5f0122c215a412c4b855d78e94-updateinfo.xml.gz >>> >>> The errata data is packaged into the yum repository into the repodata >>> folder, making things like Spacewalk automatically import errata on >>> each mirror sync. Also provides some extra features with yum for >>> viewing this data (and later DNF, I think?). >> >> ok, so the updateinfo content - we can carry that, where would the data >> come from ? > > Can whatever makes the mailing list errata messages be used as a data > source to generate updateinfo.xml? Obviously to make this work, > something would have to store a persistent history of all previously > packaged updates. It would have to be generated and shipped as part of > the metadata update when pushing new packages to the mirror. > > This is something we would very much like to see in CentOS, since > spacewalk relies on this data source for pulling in errata information. > Our current workaround is mailing list scraping and it's not reliable. > > -- > Kevin Stange > Chief Technology Officer > Steadfast | http://steadfast.net > Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel