On 06/18/2014 09:32 AM, Nathanael D. Noblet wrote: > On Tue, 2014-06-17 at 17:35 -0600, Stephen John Smoogen wrote: > >> From the EPEL side of the fence, the reason that OpenStack isn't in >> EPEL anymore is due to three factors: >> >> >> 1) You really can't parallel y install it unless you do it via >> software collections >> 2) Updates to it aren't guaranteed to be without headache (command >> come, commands go, etc) >> 3) Lifetimes of the stack are shorter and aren't supportable after >> they get replaced. > So I should clarify. Having packages in EPEL is a signal to me a as a > user that the developers/packagers will make sure their released version > works with the packages available in the repos, they are following the > packaging guidelines/standards, aren't providing newer base packages > that may break other dependencies etc. This can be signaled multiple > ways, but the biggest thing is that I know if it is in EPEL it already > exists as part of an ecosystem - it can't conflict or replace base > versions that may be needed by other apps on the system. So somehow that > message needs to be communicated. The idea that using RDO packages will > not conflict with base packages / whatever and that care is taken to > make sure it works and is tested with the targeted system. > > I'm more than willing to use not base/epel packages. However doing so > often complicates my life afterwards. Granted I would expect systems > using RDO to not be running other services/apps since it kinda doesn't > make much sense to have a cloud system, and one of the base hardware > also running mail/web whatever apps. Those might as well be part of a > cloud instance. > BUT ... RDO packages NEED to conflict with base in some ways. We should have a Cloud SIG for this and RDO would be one of participants. What we need to still hash out, IMHO, is exactly how we host the code and do the builds, etc. But I am not sure that is exactly what Rich is asking for here. I think (and I could be wrong) that what Rich is asking is for actual current RDO users on CentOS to provide input on how they (RDO) can make their current RDO installs work better??? The SIG would determine lifetimes of releases, etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140618/7735db2e/attachment-0007.sig>