On Wed, Dec 5, 2012 at 8:58 AM, Troy Dawson <tdaw...@redhat.com> wrote:
> On 12/05/2012 08:47 AM, Greg Swift wrote: > > > > On Tue, Dec 4, 2012 at 5:46 PM, Ken Dreyer <ktdre...@ktdreyer.com > > <mailto:ktdre...@ktdreyer.com>> wrote: > > > > On Tue, Dec 4, 2012 at 3:48 PM, Greg Swift <gregsw...@gmail.com > > <mailto:gregsw...@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...)
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
