Open Stack

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é <mgagne at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150304/3142caf9/attachment.html>