[Openstack-devel] OVS 2.0.1 packages in Debian

[Ben Pfaff]

Sorry about the delay in responding.  It looked like you were on
vacation for a while, and then I was on vacation myself for a while, but
now I'm back and it looks like you are too.

On Thu, Dec 19, 2013 at 04:30:02PM +0800, Thomas Goirand wrote:
> Done already. Please do:
> git clone ssh://git.debian.org/git/openstack/openvswitch.git

OK...

> Once done, you can do:
> ./debian/rules gen-orig-xz

This yields an error for me:

    blp at blp:~/tmp/openvswitch(127)$ ./debian/rules gen-orig-xz
    make[1]: Entering directory `/home/blp/tmp/openvswitch'
    make[1]: *** No rule to make target `gen-orig-xz'.  Stop.
    make[1]: Leaving directory `/home/blp/tmp/openvswitch'
    blp at blp:~/tmp/openvswitch(2)$ 

Oh, I guess I need the file from this include in debian/rules?  (But
then why does the line start with -?)
        -include /usr/share/openstack-pkg-tools/pkgos.make
Where do I get that file?  Maybe I need to go through some of
the procedure at http://openstack.alioth.debian.org/?  (How much?)

> You will notice that I did a bit of simplification in the packaging
> already. Please read debian/changelog.

Thanks, and especially for doing the rewrite of debian/copyright.  I've
meant to switch to the machine-readable format for a while but just
never found the time.

> One thing that is currently wrong, is that your tagged release currently
> include the debian folder. Please remove it completely from your
> upstream Git, or at least rename the debian folder into something like
> "debian-upstream", because otherwise it's very annoying. I currently
> removed it, and added a tag "2.0.1" in the "branch-2.0", so I could use
> git-buildpackage. Let me explain how it works.

Our repository and our releases include Debian packaging because we use
it, all the time.  For every upstream commit, the Nicira corporate
autobuilder builds Debian packages for multiple combinations of
Debian/Ubuntu distribution and architecture, and then we use those
packages for testing and, sometimes, for distribution to our customers.
And although we use it a lot, we're not the only ones who use it.  I
wouldn't want to get rid of that packaging entirely, because we and
others use it.

I'd rather maintain packaging just in one place, for example only at
alioth, but off-hand I doubt that alioth could totally supplant the
in-tree Debian packaging, because I imagine that alioth will focus on
packaging one particular version of Open vSwitch at a time (for example:
version 2.0), whereas the in-tree packaging is kept continuously
up-to-date as OVS evolves.  (Occasionally we do make a mistake, but the
autobuilder sends us the errors within an hour or two, and so we fix the
problem soon after that.)

> Thanks to debian/gbp.conf (upstream-tag = %(version)s), git-buildpackage
> is using the tag that matches the version described in debian/changelog
> to generate the difference between the upstream tarball and the package.
> This means that the tagged release cannot contain the debian folder,
> otherwise dpkg / git-buildpackage doesn't understand how to make that
> difference.

Why is it difficult to calculate the difference in that case?  I don't
quite understand.

> There are a few things which I don't really understand in the current
> packaging. Let me ask a few question.
> 
> - Why do you have a debian/automake.mk? How is it used? Couldn't we just
> get rid of it?

debian/automake.mk mainly ensures that "make dist" includes the Debian
packaging files in the generated tarball, so that users of the generated
tarball can generate Debian packages.

> - I saw there's a control.modules.in file. My understanding is that it
> is used to sed the _KVERS_ variable. Though there's a header for the
> source package, which doesn't even seem to be up-to-date. There's also a
> rules.modules which seems to be related. Do we really need this? Isn't
> the dkms package just enough? I do believe that the old module-assistant
> thing should be killed, since the dkms thing is so much better and easy
> to use. Your thoughts welcome!

I like DKMS better too.  But can DKMS generate packages for
distribution?  One typical use case for Open vSwitch is a cloud provider
with thousands of hypervisors all running the same kernel.  Some of
these cloud providers don't want to build a kernel module from source on
every hypervisor.  They much prefer to build and package a kernel module
once and distribute the .deb to their hypervisors.  I had the impression
that DKMS could not do that, which is why we retained module-assistant
support.  But if DKMS can handle it, I'm happy to drop module-assistant.

> > Probably we should start a separate
> > discussion on whether only packaging LTS releases (to
> > unstable/testing) make sense, too.
> 
> Please feel free to start a separate topic about this in the list.

OK.  I'll wait until the existing discussion has made some progress ;-)