On Wed, 2009-07-08 at 13:41 +0200, Olaf Mueller wrote: > CentOS, epel and other yum repos are all serious projects with the aim > to be stable as possible. I always thought rpmforge is such a project > too.
Actually, *you* are missing the point here and the point in question is "you can't trust anybody until you have the SLA with them". None of the projects above provide you with the SLA: some (read CentOS) have a good track record of keeping up to the level, some (EPEL / RPMForge) are serving you on the best effort basis. At the same time, you *shouldn't* confuse the reputation with guaranties when it comes to administering mission-critical systems. If you *need* guaranties, go sign up for RHEL, their app-platform offering and whatever else they support. If you pick the other way round, but still identify your systems as critical, the *only* way to go is to set up separate testing machine with a local repo and cherry-pick packages from EPEL or RPMForge (refer to Dag's suggestion of not using RPMForge *directly*), before they hit production. If you failed to do so and now complain about missing dependencies impacting your *security*, it means that either (a) you label a system as critical, but fail to treat it accordingly or (b) you have a misconception about how things work at a very basic level. It is important to note, that nobody lures you into thinking that they take responsibility for providing you with the enterprise-grade packages while they aren't. Dag clearly states, that RPMForge is a hobby project. The catch here is that unless there is an SLA, stability remains a subjective criterion. RPMForge is pretty much stable for me, but this might not be the case for you. I declare it stable, you tell it sucks and we are both right. Wow! Now having that said, I hope you understand why your wrong statements like this one: > Do I something missunderstood here, or behaved rpmforge like a > testing repo without saying that this is testing only and not stable? caused this heated discussion. Unless you volunteer as a tester, packager, infrastructure provider etc. please confine yourself to the reports only. > Maybe a 'testing before delivering' rpmforge-repo would be a good > choice. But you are right, nobody forces me to use rpmforge. This is already being done for awhile. Unfortunately as far as I understand there is no streamlined way to do so for the Perl packages and it's quite difficult to track interdependency problems. -- Sincerely yours, Yury V. Zaytsev _______________________________________________ users mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/users
