<div dir="ltr"><div>I like cowbuilder... pbuilder using copy on write qcow's for the build environment.  Most folks automating debian package creation use pbuilder.<br><br></div>-Matt<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 11:31 AM, Mathieu Gagné <span dir="ltr"><<a href="mailto:mgagne@iweb.com" target="_blank">mgagne@iweb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm currently experimenting with fpm.<br>
<br>
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.<br>
<br>
This bothers me a lot because my current workflow looks like this:<br>
1) Fork Ubuntu Cloud Archive OpenStack source packages<br>
2) Apply custom patches using quilt [1]<br>
3) Build source and binary packages using standard dpkg tools<br>
4) Upload source and binary packages to private APT repository with dput<br>
5) Install new packages<br>
<br>
(repeat steps 2-4 until a new upstream release is available)<br>
<br>
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:<br>
<br>
If I used fpm instead, step 4 would fail because there is no .changes control file required by dput to upload to APT.<br>
<br>
This raises the question:<br>
<br>
How are people (using fpm) managing and uploading their deb packages for distribution? APT? Maven? Pulp? Black magic?<br>
<br>
I really like APT repositories and would like to continue using them for the time being.<br>
<br>
<br>
fpm vs native tools<br>
-------------------<br>
<br>
To continue on the general subject of packaging:<br>
<br>
I do understand that fpm gives you some advantages like:<br>
- being able to run the packaging step on non-Debian operating systems<br>
- not having to create/manage a debian/ folder.<br>
<br>
Are those really advantages?<br>
<br>
With Docker, Vagrant and friends, you always have access to a "native" operating system to package your stuff and use their tooling.<br>
<br>
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.<br>
<br>
So I thought about something regarding OpenStack packaging (for operators, not upstream):<br>
<br>
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]<br>
<br>
Why not doing the same for Debian packages? If such thing exists, would you use it?<br>
<br>
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)<br>
<br>
<br>
Virtualenv<br>
----------<br>
<br>
I understand that people also like Python virtualenv because they are (mostly) self-contained: no need to natively package python modules.<br>
<br>
That's super interesting and I'm planning on trying it out myself in the following months.<br>
<br>
The giftwrap project [3] leverages fpm by automating the git checkout and virtualenv parts.<br>
<br>
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)<br>
<br>
Does it bother anyone else? Or are people using giftwrap not using Puppet and APT repository to deploy their stuff?<br>
<br>
<br>
Other system packages<br>
---------------------<br>
<br>
What about other system packages like libvirt or QEMU. Anyone (patching and) packaging them? If so, how are you doing it? git-buildpackage?<br>
<br>
Would there be interests in sharing the tooling and methodology?<br>
<br>
<br>
So how can we have the cake AND eat it? =)<br>
<br>
<br>
[1] Using gbp-pq from git-buildpackage to keep some level of sanity<br>
[2] <a href="https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs" target="_blank">https://github.com/stackforge/<u></u>anvil/tree/master/conf/<u></u>templates/packaging/specs</a><br>
[3] <a href="https://github.com/blueboxgroup/giftwrap" target="_blank">https://github.com/<u></u>blueboxgroup/giftwrap</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Mathieu<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</font></span></blockquote></div><br></div>