On Thu, Jul 30, 2015 at 7:10 AM, Karanbir Singh <mail-lists at karan.org> wrote: > On 30/07/15 11:17, Sandro Mathys wrote: > >> Right, that sounds like a plan once we're ready to be included in the >> distro. But we face tons of deps (mostly java libs/jars) that we need >> to bundle first. That's why I'm explicitly asking about inclusion of a >> midonet-release package, not MidoNet as a whole. What's the criteria >> and process for that? > > There really isnt one. We wont include the -release package directly > unless the content it reflected on was also part of the CentOS > ecosystem, either in a SIG or part of the upstream relationship ( eg. > for stuff in CentOS Extras ). > > There have been conversations kicking around about getting a policy in > place and have some sort of a formal test and eval for content standards > in a third party repo external to CentOS - but getting something in > place is non-trivial and clearly you guys have packaging problems at > this point anyway. > > regards, I'm a bit surprised at this: do you consider "epel-releae" to be part of the "CentOS ecosystem"? I suppose with the tight relationship between EPEL and RHEL, it could be. But there are many 3rdparty groups, such as rpmforge and rpmfusion and percona, that publish their own third party repositories quite effectively. It can be tricky to sort out cross-compatibility and dependencies, certainly, especially when different 3rdparty repositories publish the same comopnents or compoents with the same metadata. The overlaps between EPEL and RPMforge for nagios are some of my favorites, along with the "mysql-libs" metapackage amyng alternative MySQL package repositories. Sandro, if there are overlaps between your components and EPEL or basic CentOS packages, I'd urge you to bite the bullet and set up your own third party repository. It's work, but it will help avoid confusion.