The packaging source in the OVS repository has drifted away from
what is currently in Debian and Ubuntu.  This state is problematic
because from time to time someone tries to build packages from the
upstream OVS debian package source and then expect that package to
work with up-/down-grades from-/to/ distro versions.

To support the on-going work to remove the out of tree OVS kernel
driver from the repository [0], an update to the debian packaging
is also required.  On the back of the discussion in [0] we agreed
that replacing the current version with what Debian and Ubuntu
is currently converging on would be preferable.

This commit is a first in a series to update the upstream OVS
debian packaging source to be up to date with what is currently
in Debian and Ubuntu.

0: https://mail.openvswitch.org/pipermail/ovs-dev/2022-June/394634.html

Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

OVS 1.7 was released in July 2012, so by the time current OVS is released,
it will be almost four years old.  I think that this is long enough to
remove special upgrade code.

It's almost impossible to do this upgrade in any case since there is
no overlap in the base kernel versions supported by the out of tree
modules in the two versions (the only possibility is running the new
version of OVS on the upstream module from Linux 3.3).

Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jesse Gross <jesse@kernel.org>

Currently, every time we install the non-dkms openvswitch kernel package,
we restart openvswitch. This has no useful effect when an Open vSwitch kernel
module is already loaded, because "/etc/init.d/openvswitch restart" does not
load the new version of the kernel module.

With this patch, we start openvswitch if there is no kernel module
currently loaded (which is a case for a fresh install of openvswitch). This
will load the kernel module.

If someone wants to use the latest kernel module after an upgrade, they need
to run "/etc/init.d/openvswitch-switch force-reload-kmod" manually.

Issue #13556
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>

Until now, the postinst for kernel modules built by the Debian packaging
has simply run "depmod -a", which is wrong, since this command rebuilds
the dependencies for the *running* kernel, which is not necessarily the
kernel for which modules are being installed.

The dh_installmodules script automatically adds the correct invocation of
depmod to the postinst script, so this commit switches to using that
instead.

This commit moves the kernel modules from /lib/modules/$KVERS into the
"kernel" subdirectory of that directory because dh_installmodules does not
support modules that are directly in the $KVERS directory.

CC: Sajjad Lateef <slateef@nicira.com>