[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: Rethinking EPEL at FUDcon Lawrence 2013






On Thu, Dec 6, 2012 at 12:11 PM, Stephen John Smoogen <smooge gmail com> wrote:
On 6 December 2012 10:58, Matthew Miller <mattdm 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]