[ovs-dev] packaging (was: Re: [PATCH v2] Add multi-column index support for the) Python IDL

Ben Pfaff blp at ovn.org
Tue Apr 17 21:19:24 UTC 2018

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

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+

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).

More information about the dev mailing list