[Openstack-devel] OVS 2.0.1 packages in Debian
Thomas Goirand
zigo at debian.org
Fri Jan 10 04:18:22 UTC 2014
On 01/10/2014 01:47 AM, Ben Pfaff wrote:
> Sorry about the delay in responding.
No worries.
> 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...
As I wrote, I need to restart from scratch and cherry-pick some changes.
I was a bit too agressive.
>> 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)$
You need to install openstack-pkg-tools.
> Our repository and our releases include Debian packaging because we use
> it, all the time.
It just needs to live in a separate branch. That's the only way to do
things if you want to use git-buildpackage, and that's not harder to
manage. I would suggest to use git-buildpackage in your CI script as
well. Let me know if you need help for that.
> 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.)
This can also happens with different branches.
>> 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.
Because in Debian, the orig.tar.{gz,xz} needs to not include the debian
folder. So if the upstream branch contains the debian folder, there's no
way for git-buildpackage to work.
>> 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.
IMO, your "make dist" should generate an orig file, and a debian.tar.gz
file *separately*, so it shouldn't be a problem.
> 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.
DKMS can be used in all cases, as long as you install the needed kernel
headers and kbuild packages. Though if integrators think it's not
efficient to do that, let's keep the m-a thing.
Also, another topic. I've chatted quickly with James Page from
Canonical, and he told me he thinks it'd be nice if both Debian and
Ubuntu were working on the same OVS packages. I can only agree that
reducing the amount of packaging effort would be awesome!
Thomas
P.S: I'll try to work again on the OVS packaging today and fix the
current Alioth repository removing the cruft I've done.
More information about the Openstack-devel
mailing list