ovs-vswitchd in the openvswitch-switch package is tightly coupled to its
database schema. During development, it's possible to change the schema
without changing the Open vSwitch version number, which makes it possible
for the openvswitch-switch and openvswitch-common packages to get out of
sync: openvswitch-switch requires the same version of openvswitch-common,
but if the version number doesn't get updated that has no effect.
Actually putting the schema and ovs-vswitchd (its primary user) in the
same package prevents them from getting out-of-sync. This commit also
moves ovsdb-tool because that program often works directly with OVSDB
schemas and so there's not much point having it around without a schema to
work with.
Originally I intended this as just a cleanup, but as a side effect it also
installs some files from the install tree in debian/tmp instead of from
_debian. This should avoid a reported problem in which ovs-bugtool was
being created in the source directory instead of the build directory (I
still don't see why this happened).
Reported-by: Sébastien RICCIO <sr@swisscenter.com>
Tested-by: Sébastien RICCIO <sr@swisscenter.com>
Acked-by: Simon Horman <horms@verge.net.au>
CC: Simon Horman <horms@verge.net.au>
All of the xen-bugtool plugins that OVS has previously installed only under
XenServer are equally useful with Debian and other distributions, so
this commit installs and uses them everywhere.
ovs-bugtool is no longer Debian-specific, so install it everywhere. (On
XenServer, specifically, we do not install it, because there xen-bugtool
already exists.)
ovs-bugtool creates a tarball of useful information which people
can submit with bug reports. The source is copied from xen-bugtool
with the xen specific removed or changed.
Until now, the OVSDB IDL annotations have been glommed together with the
schema information in a single file, and then we've used ovsdb-idlc to
extract the schema from that file. This commit reverses the process:
the schema and the annotations are stored separately and then glommed
together as necessary at build time.
This new arrangement has a few advantages:
- We can now easily have multiple different sets of IDL annotations
for a single OVSDB schema. For example, some users may not need
access to columns that other users do.
- Bugs in ovsdb-idlc cannot screw up the underlying schema (as shown
by a recent commit).
This appears to work in that it creates the database on installation,
starts and stops the programs and loads and unloads the kernel modules at
the right times, but it has not been tested beyond that.
