I like cowbuilder... pbuilder using copy on write qcow's for the build environment. Most folks automating debian package creation use pbuilder.
-Matt On Wed, Mar 4, 2015 at 11:31 AM, Mathieu Gagné <mga...@iweb.com> wrote: > Hi, > > I'm currently experimenting with fpm. > > I learned that fpm does not generate the files needed to upload your new > package to an APT repository. Since the package type built by fpm is > binary, that file would be the .changes control file. > > This bothers me a lot because my current workflow looks like this: > 1) Fork Ubuntu Cloud Archive OpenStack source packages > 2) Apply custom patches using quilt [1] > 3) Build source and binary packages using standard dpkg tools > 4) Upload source and binary packages to private APT repository with dput > 5) Install new packages > > (repeat steps 2-4 until a new upstream release is available) > > While I didn't test fpm against OpenStack packages, I did test it with > other internal projects. I faced the same challenges and came to similar > conclusions: > > If I used fpm instead, step 4 would fail because there is no .changes > control file required by dput to upload to APT. > > This raises the question: > > How are people (using fpm) managing and uploading their deb packages for > distribution? APT? Maven? Pulp? Black magic? > > I really like APT repositories and would like to continue using them for > the time being. > > > fpm vs native tools > ------------------- > > To continue on the general subject of packaging: > > I do understand that fpm gives you some advantages like: > - being able to run the packaging step on non-Debian operating systems > - not having to create/manage a debian/ folder. > > Are those really advantages? > > With Docker, Vagrant and friends, you always have access to a "native" > operating system to package your stuff and use their tooling. > > As for debian/, I feel not everyone like Debian packaging for various > reasons but I happen to still like them. They serve me very well. > > So I thought about something regarding OpenStack packaging (for operators, > not upstream): > > What if there was a place to get OpenStack package Debian *skeletons* so > you can build your own packages from master? AFAIK, the Anvil project ships > with .spec files. [2] > > Why not doing the same for Debian packages? If such thing exists, would > you use it? > > One important requirement for me is that package should be "compatible" > with native packages so Puppet can manage them without too much > modifications. This means Puppet shouldn't fail because it couldn't find > the nova-compute package. (because fpm only created the all-in-one nova > package) > > > Virtualenv > ---------- > > I understand that people also like Python virtualenv because they are > (mostly) self-contained: no need to natively package python modules. > > That's super interesting and I'm planning on trying it out myself in the > following months. > > The giftwrap project [3] leverages fpm by automating the git checkout and > virtualenv parts. > > Unfortunately, the packages generated aren't 100% compatible with Puppet > nor can they be uploaded to an APT repository. (still missing that .changes > control file) > > Does it bother anyone else? Or are people using giftwrap not using Puppet > and APT repository to deploy their stuff? > > > Other system packages > --------------------- > > What about other system packages like libvirt or QEMU. Anyone (patching > and) packaging them? If so, how are you doing it? git-buildpackage? > > Would there be interests in sharing the tooling and methodology? > > > So how can we have the cake AND eat it? =) > > > [1] Using gbp-pq from git-buildpackage to keep some level of sanity > [2] https://github.com/stackforge/anvil/tree/master/conf/ > templates/packaging/specs > [3] https://github.com/blueboxgroup/giftwrap > > -- > Mathieu > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
