<div dir="ltr">Hey,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 30, 2018 at 11:48 AM, Javier Pena <span dir="ltr"><<a href="mailto:jpena@redhat.com" target="_blank">jpena@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As you're probably aware, there is an OpenStack rpm-packaging project [1], where the RDO community has been collaborating with people from other rpm-based distributions. We have been successful in reusing some tools created by that project [2][3], but we've never been able to reuse the spec file templates generated by the project, besides openstack-macros and some python 3 tests done during the Rocky cycle.<br>
<br>
As a community, we need to decide what we want our involvement in the project to be:<br></blockquote><div><br></div><div>Agreed, I'd like to have this finally clarified. I fully support as close integration with rpm-packaging as viable.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Only get involved in the tooling side, if we have no plans to reuse the spec templates in the future.<br></blockquote><div><br></div><div>We are already involved on the tooling side, renderspec and pymod2pkg support rendering fedora/el/suse RPMs. Even if we chose not to reuse the specs, we should at least keep using pymod2pkg to translate python module names to RPM Requires because it's a generic solution that can be extended to be used on any platform and it should be easier to maintain together as well.<br><br>> - Try a deeper integration with the specs.<br><br>That would (eventually) be the most efficient route leveraging the power of collaboration. We should look at howto make this happen and see if there are good reasons not to. As Neal pointed out, biggest concern is suse's singlespec, so this boils down to seeing if we can use that. I need to look more but it looked decent to me on first look so I'll continue investigating this in hopes we can converge.<br><br><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">From another point of view, there aren't **that many** RPM distros, are there? Working towards common RPM tooling together seems beneficial to all parties.</span><br style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Other alternatives?<br></blockquote><div><br>This looks like like a binary choice to me - either we use the rpm-packaging specs or we don't, nothing in between.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Each option will carry its own consequences, e.g. if we stop contributing to the spec templates we should stop the 3rd party CI jobs and VMs that support them.<br></blockquote><div><br></div><div>Yes. We should either fully reuse the spec templates or stop contributing to them and stop the 3rd party CI jobs and VMs that support them. <br><br><br>Cheers,<br>Jakub</div></div></div></div>