RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Greg Swift]

On Wed, Dec 5, 2012 at 8:58 AM, Troy Dawson <tdawson at redhat.com> wrote:

> On 12/05/2012 08:47 AM, Greg Swift wrote:
> >
> > On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <ktdreyer at ktdreyer.com
> > <mailto:ktdreyer at ktdreyer.com>> wrote:
> >
> >     On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <gregswift at gmail.com
> >     <mailto:gregswift at gmail.com>> wrote:
> >     > I'm personally inclined to lean toward the concept I was pushing
> >     in the
> >     > thread discussing multiple versions [1].  I'd imagine that a 'api
> >     stable'
> >     > 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.
> >
> > -greg
>
> 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.
>

I'm very amused with myself for forgetting about the security plugin
(mainly cause I never used it but still...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121205/b76503ff/attachment.htm>