[rdo-dev] RDO community involvement in OpenStack's rpm-packaging project
jruzicka at redhat.com
Wed Sep 5 15:47:02 UTC 2018
On Thu, Aug 30, 2018 at 11:48 AM, Javier Pena <jpena at redhat.com> wrote:
> Hi all,
> As you're probably aware, there is an OpenStack rpm-packaging project ,
> 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 , 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.
> As a community, we need to decide what we want our involvement in the
> project to be:
Agreed, I'd like to have this finally clarified. I fully support as close
integration with rpm-packaging as viable.
> - Only get involved in the tooling side, if we have no plans to reuse the
> spec templates in the future.
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
> - Try a deeper integration with the specs.
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.
>From another point of view, there aren't **that many** RPM distros, are
there? Working towards common RPM tooling together seems beneficial to all
- Other alternatives?
This looks like like a binary choice to me - either we use the
rpm-packaging specs or we don't, nothing in between.
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev