Open Stack

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