RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Greg Swift]

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.

A specific scenario that raises accountability concerns would be if the
package I have installed is a security risk and the only fix is the
'breakable update'.  To address that would be a state such as 'required
breakable update - security risk'.  If you attempt update all, yum would
fail out with an error explaining why.  This is the only time I'd suggest
an actual error because of the accountability aspect.  The error prevents
it from being completely ignored, unless the result of the process is
blatantly ignored, and I can't help there.

If there is a requirement to stay on the 'insecure' version, place the
package into the standard exclude list and then this would not come into
play.

The plugin would have to support the concept of versioning.  Allowing
definitions along the lines of:

package version 2+ is a breakable update for versions <2 or 1.*

Not only does this keep the feed content smaller, as it isn't required for
every released version, but if there needs to be a security update for the
1.* release, that is doable without interfering with the 2.* releases while
using the same repository.

If designed and implemented well this might be an interesting path towards
allowing newer versions of lots of software, even in base RHEL.  Obviously,
it wouldn't work for everything... but it has potential.


> If I update 100 machines, I am not going to look at all the spew from
> yum, and if I don't specifically look at my logs often am I going to
> notice this.
>

So, I feel that falls under the realm of an admins responsibility, and most
facilitation for the handling of it should readily come from what is
described above.  Its not like I'm suggesting we push a potentially broken
package, I'm talking about letting their system keep running as it is,
unless they specifically update it.

If I install a new machine with updates enabled, would I notice this
> before the machine was deployed?
>

This concept is specific to updates, not fresh installs.  During a new
install one would get the latest version of the software available , just
like today.  If a specific version is defined, and there is a 'breakable
update' available before you deploy, then no, it would not be installed on
a 'yum update'.

-greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121206/78bf3c51/attachment.htm>