On Wed, Dec 5, 2012 at 5:53 PM, Kevin Fenzi <kevin@scrye.com> wrote:

On Wed, 5 Dec 2012 10:33:04 -0500
Matthew Miller <mattdm@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