On 10/18/2016 02:37 AM, Ian Cordasco wrote: > On Oct 17, 2016 7:27 PM, "Thomas Goirand" <z...@debian.org > <mailto:z...@debian.org>> wrote: >> >> On 10/17/2016 08:43 PM, Adam Harwell wrote: >> > Jim, that is exactly my thought -- the main focus of g-r as far as I was >> > aware is to maintain interoperability between project dependencies for >> > openstack deploys, and since our amphora image is totally separate, it >> > should not be restricted to g-r requirements. >> >> The fact that we have a unified version number of a given lib in all of >> OpenStack is also because that's a requirement of downstream distros. >> >> Imagine that someone would like to build the Octavia image using >> exclusively packages from <your-favorite-distro-here>... >> >> > I brought this up, but >> > others thought it would be prudent to go the g-r route anyway. >> >> It is, and IMO you should go this route. > > I'm not convinced by your arguments here, Thomas. If the distributor > were packaging Octavia for X but the image is using some other operating > system, say Y, why are X's packages relevant?
What if operating systems would be the same? As a Debian package maintainer, I really prefer if the underlying images can also be Debian (and preferably Debian stable everywhere). > I would think that if this > is something inside an image going to be launched by Octavia that > co-installibilty wouldn't really be an issue. The issue isn't co-instability, but the fact that downstream distribution vendors will only package *ONE* version of a given python module. If we have Octavia with version X, and another component of OpenStack with version Y, then we're stuck with Octavia not being packageable in downstream distros. > I don't lean either way right now, so I'd really like to understand your > point of view, especially since right now it isn't making much sense to me. Do you understand now? :) Cheers, Thomas __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev