Steve Linabery <[email protected]> writes: > On Thu, Apr 04, 2013 at 12:19:19PM -0400, Scott Seago wrote: >> On 04/04/2013 11:34 AM, Matt Wagner wrote: >> >On 4/4/13 10:22 AM, Mo Morsi wrote: >> >>Is there any interest in continuing to support conductor / aeolus-cli in >> >>Fedora? The packages are currently broken there and from what I gather >> >>the team's been more focused on development and releasing gems recently. >> >>Unless there are any objections, I will retire the packages. If there is >> >>demand for support in Fedora in the future, we can easily loop back >> >>around then. >> > >> >While I'm sorry to see them go, I think it's the best course of >> >action. They've been broken for a long time, and I think that >> >having broken packages is considerably worse than having no >> >packages. If someone were committed to maintaining them, they've >> >been MIA for months. >> > >> >I vote to pull them from Fedora, but to maybe think as we go >> >forward about maybe continuing to package RPMs, just not in >> >Fedora. The pure-Ruby approach / dev-tools approach is great for >> >developers, but I'm not sure how well it will work for people >> >wanting to run Aeolus "for real." >> > >> >-- Matt >> Yeah -- not only that, the list of conductor deps that are not in >> fedora has grown as well (tim, ldap_fluff, (shortly) alberich, >> etc.), so getting the packages working wouldn't just be a matter of >> fixing them, but also a matter of getting new dependencies into >> fedora at the same time. >> >> Scott >> > > Also AFAIK no one has tested an aeolus-configure-based install since 2012. So > even if we had RPMs it's not likely that they'd be consumable without > additional effort on the configure front. > > But yeah, the fact that we didn't have packages for the external deps really > stifled RPM package maintenance. Around that time we were shifting to the > dev-tools-based delivery/install which added to our indifference toward RPM. > > Another vote for 'retire' from me. Should probably also include > aeolus-configure. > > Steve|eggs
+1 to killing configure in addition to the others. I also remember dbomatic and/or delayed_job didn't work either since some of the gem dependencies have changed out underneath as well.
