RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Stephen John Smoogen]

On 6 December 2012 10:13, Greg Swift <gregswift at gmail.com> wrote:
>
>
>
> On Wed, Dec 5, 2012 at 5:53 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>>
>> On Wed, 5 Dec 2012 10:33:04 -0500
>> Matthew Miller <mattdm at fedoraproject.org> wrote:
>>
>> > On Wed, Dec 05, 2012 at 08:58:44AM -0600, Troy Dawson wrote:
>> > > Not volunteering at the moment because I don't have the cycles, but
>> > > I really like that idea.
>> > > Something similar, except opposite, of the security plugin.  If a
>> > > package has the "breakable update" option set, then don't update it
>> > > unless they do the "--reallyupdate" option.  But also give them a
>> > > nag that says the package has an update.
>> >
>> > +1 to this
>>
>> -a lot. ;)
>>
>> Anything that requires someone to read output from updates is doomed.
>
>
> I agree with this sentiment.  Which is why you don't _have_ to read output.
> The automatic exclusion is the plugins behavior, with the goal of leaving
> your system in a running state.  Any output is there to provide an
> explanation for the lack of an update when looked for.
>
> Ideally, we are talking about defining an expected system behavior.  It will
> take communication on top of the plugin creation and feed updating.

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.


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd