RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Greg Swift]

On Thu, Dec 6, 2012 at 12:11 PM, Stephen John Smoogen <smooge at gmail.com>wrote:

> On 6 December 2012 10:58, Matthew Miller <mattdm at fedoraproject.org> wrote:
> > On Thu, Dec 06, 2012 at 10:45:54AM -0700, Stephen John Smoogen wrote:
> >> Ok looking at the security plugin code it seems it bases its decisions
> >> on what is already stored in the repodata. That being the case any
> >> sort of plugin is going to need to have extra stuff stored in repodata
> >> which means changes to createrepo, rpm, yum-utils, and yum. I don't
> >> think this is going to happen so we might as well look for some other
> >> solution.
> >
> > Why not? The security metadata wasn't always there and _that_ feature got
> > added.
>
> It got added before RHEL-6 was out the door. EPEL does not control
> yum, createrepo, rpm or yum-utils for Red Hat Enterprise Linux.
> Getting it into there means working with Fedora yum/rpm developers on
> how it will be stored.. getting it working in Fedora, then figuring
> out how to back port that to the RHEL-5 and RHEL-6 yum's. Then working
> with Red Hat on allowing for a large ABI break where old yum users are
> guarenteed to still be able to make yum commands without yum crashing
> and that new yum users won't crash when reading old yum repos.
>
>
If updateinfo.xml could store the data, would the addition of an alternate
'update' type break existing systems?  From what I can tell updateinfo.xml
is populated by parsing errata feeds.  If this data could be presented as a
specifically formatted errata,  which to me makes a bit on sense because
its just an update, then the updateinfo.xml generator and the plugin would
be the primary change points.  As long as the clients don't blow up at an
alternate <update type='breakable'> or whatever, then maybe there wouldn't
be a large ABI break.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121206/7ed64df7/attachment.htm>