<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Nov 22, 2014, at 5:08 AM, Michael Chapman <<a href="mailto:woppin@gmail.com">woppin@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 8:51 AM, Craig Tracey <span dir="ltr"><<a href="mailto:craig@craigtracey.com" target="_blank">craig@craigtracey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great input Kris. We also took a look at Anvil, and as you mention it is heavily biased for RH based distros. <div><br></div><div>With regard to your requirements:</div><div>1) Under the cover for Giftwrap we use fpm for package creation, so debs and rpms are merely a flag to toggle.</div></div></blockquote><div><br></div><div>During the Paris session someone specifically mentioned they didn't want to use fpm, and wanted plain spec files instead. If that person is on this list, or if there's anyone else in that position, care to elaborate? Is there a specific limitation people are concerned about?</div><div> </div></div></div></div></div></blockquote><div><br></div><div>We get this request pretty commonly - the most common use case I hear like this is people who want to start with a "reference" build (RDO / OSP, UCA, etc) and minimally customize. So they want to stay with the original spec or debian/* packaging and tweak, vs package de novo</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2) Giftwrap is targeted for precisely this workflow. We pull our OpenStack source from a forked git repo, with any patches applied. The giftwrap manifest allows for specification of repo as well as ref.</div></div></blockquote><div><br></div><div>I asked you about this in Paris, but for the benefit of the list, what about native packages? I find I need to package things like libvirt as well. As a community are we expecting to run one packaging tool for Openstack's python packages and one tool for everything else, or do we expect that to be combined into a single tool that can handle both?</div><div> </div></div></div></div></div></blockquote><div><br></div><div>Strong preference for same tool doing both. Which couples with the above point to land on "need a generic rpm / deb builder" at least for those use cases</div><div><br></div></body></html>