On 12/05/2012 08:47 AM, Greg Swift wrote:
> On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <ktdreyer ktdreyer com
> <mailto:ktdreyer ktdreyer com>> wrote:
> On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <gregswift gmail com
Not volunteering at the moment because I don't have the cycles, but I> <mailto:gregswift gmail com>> wrote:
> > I'm personally inclined to lean toward the concept I was pushing
> in the
> > thread discussing multiple versions . I'd imagine that a 'api
> > repo and a 'rolling' repo would be less support effort than
> attempting to
> > manage >8 repositories per major release and the security updates
> that need
> > to be applied on older version.
> My main concern with multiple EPEL repos is that users will be in a
> worse condition security-wise. Many users will download an application
> from the "api stable" repo, but they will not realize that no one is
> doing backports any more, because all the interested EPEL maintainers
> left that behind to focus on the "rolling" repo.
> The analogy that comes to my mind is Fedora: What if we kept old
> Fedora releases going back all the way to Fedora 6 open to maintainers
> to patch on a voluntary basis, and we never really announced EOL for
> any Fedora release? Fedora users would have to know enough to keep
> jumping along with whatever's maintained.
> It seems to me that we have to choose between occasional instability
> and insecurity. I'd rather EPEL's reputation err on the side of
> instability rather than insecurity.
> I can back that line of thought. Plus providing 1 path means less
> change! :)
> > So, unless someone wants to turn EPEL into a paid service, #1 is out
> > (hey... thats an interesting concept...)
> Maybe money does have to enter the picture at some point. Corporations
> should commit to pay salaries for more developers to do EPEL backports
> if it's important to their businesses.
> So... anyone got any motivation in pushing a product internally @ Red
> Hat that does this? :)
> Also.... I hadn't mentioned it before on here, because in general
> mentioning tends to mean you have to do it and I don't really have the
> cycles available. But as of this morning I figured I'd float the
> concept anyways.
> What would it take to basically have a yum plugin would check a
> 'notification' feed (something simple like rss or atom) about a specific
> repository. Notifications found on that feed would throw messages in
> the yum output and /var/log/messages. This feed could provide notices
> like 'Hey, this version is deprecated and insecure, you need to
> update'. An extension of this might be that it marks the package as an
> 'exclude' if it can't just be updated without interference. This would
> allow a notification method, and a way for users to not get an update if
> its going to break them, but also allowing the main page to just
> continuously be updated.
> Then this package could possibly be a required package from the
> epel-release package.
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.