On Sat, Apr 14, 2018 at 12:19:02PM -0300, Raymond Burkholder wrote: > On 04/13/2018 02:52 PM, Ben Pfaff wrote: > >On Fri, Apr 13, 2018 at 10:27:03AM -0500, Terry Wilson wrote: > >>One could argue that if if distro packaging is the issue, then distros > >>could patch in the simple try/except ImportError and add the > >>sortedcontainer code like I did above. > > > >I'm quite sympathetic to that viewpoint--I think that OVS currently has > >far too much distro-specific stuff in it. In the long run I'd like to > >drop the Debian and Red Hat and XenServer packaging from the tree. As a > > How would it work then, if, .. I enjoy the fact that I can run Master, use > the tools in the tree to build my Debian packages, and then install those > packages on the machines where they need to be? > > >Debian developer myself, I know that it's not actually helpful for > >upstream to provide packaging. > > And if by upstream, you mean the distribution? They can be quite behind at > times. Debian Stretch has 2.6, and nothing in Stretch-Backports. Buster > does have 2.8 at the moment, but Buster can be very unstable for > consistently building environments on demand.
In this case, by "upstream" I mean OVS developers and by "downstream" I mean a distribution such as Debian or Red Hat. There's a couple of things going on here. One is that I think there is much less pressure than usual on downstream to keep OVS packaging up-to-date because we maintain packaging upstream. I think that if OVS upstream stopped shipping packaging, downstreams would eventually adapt by updating packaging more frequently. Also, I suspect that most users run from a release or at least a release branch. On a release branch, usually the packaging changes little, or at least the packaging changes due to OVS changes are minimal, since OVS itself doesn't change much on release branches. I currently have a selfish reason to keep packaging in the tree, which is that VMware internally uses both the .deb and .rpm packaging as part of its internal processes (and releases to customers). We're working on getting together and contributing to OVS a container build and making that what we use internally and provide to customers. So I have motivation to make sure that the containerization is good quality too, since otherwise customers will be unhappy. (At that point, I'll be happy to transition to emeritus status as a Debian developer, since being able to directly contribute to OVS downstream packaging--which I do badly--is about the only reason I stick around there after 20+ years.) So, if we do manage to get rid of packaging, it'll only be because there's an acceptable alternative. Your options will basically be: * Use the containers, for any branch or master. We might even publish binaries, dunno yet. You can be sure they'll be pretty good since we'll actually use them too. * Use packaging from your favored distro, for some release branch. * Help out downstream with keeping the packaging up-to-date with master (or be patient and wait for other downstream folks to do the same). _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
