Hello,

I was thinking about correct approach how to package Contrail packages
that are bound to specific OpenStack version.

First I wanted to use same mechanism and build in contrail-packages, but
contrail-vnc way is per contrail version and it doesn't seem that adding
Openstack logic is what we really want (as we want to avoid creation of
similar ugliness like contrail-packaging just in new coat).

Next I came with a solution that is clean and used by many Debian
packaging projects (and also for all package builds in tcp cloud) -
git-buildpackage (aka gbp) way.

I have packaged contrail-nova-extensions as a reference [1] for multiple
Openstack versions (Juno, Kilo) and uploaded finished package on our
Launchpad [2]

Quick summary on how gbp works:

 - there's upstream branch with main code (master branch in this case)
 - tag per upstream release (eg. upstream/0.1, upstream/0.2 - names can
   be customized so it can be only 0.1, 0.2, etc.)

 - branch per debian release, in this case it's bound to both distro
   version and OpenStack version (eg. debian/trusty-juno,
   debian/trusty-kilo)

   - these branches contains debian directory with all the packaging
     stuff and merged upstream code of specific version
   - upstream version tag is determined by version in debian/changelog
     Eg. debian/trusty-juno builds using upstream/0.1 tag but
     debian/trusty-kilo uses upstream/0.2

 - branches, tag names and overall behavior is determined by
   debian/gbp.conf
 - working with tags and branches is made easier using `gbp` tool as
   well as package build itself is automated using `git-buildpackage`
   And of course this all can be wrapped by Makefile, Scons, etc.

For more informations on git-buildpackage, you can check slides from my
workshop [3] with more useful info on Debian packaging or gbp docs [4].

Beside of gbp and quilt source packages approach, we can use native
format. But it is usualy only used for software done exclusively for
Debian and in my opinion not a good way in this case.

Of course if we agree on this approach, it will need some co-operation
with Juniper CI guys.
But we want to push all changes and enhancements to upstream and
hopefully once drop our packaging. Or in the best case, have Contrail
packages in Debian distribution.

I welcome any ideas,

Filip

---
[1] https://github.com/tcpcloud/contrail-nova-extensions/tree/debian/trusty-juno
[2] https://launchpad.net/~tcpcloud/+archive/ubuntu/kilo/+packages
[3] https://fpy.cz/pub/slides/debian-packaging/#/step-20
[4] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Dev mailing list
[email protected]
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org

Reply via email to