Re: [rdo-dev] RDO community involvement in OpenStack's rpm-packaging project
Hey,
On Thu, Aug 30, 2018 at 11:48 AM, Javier Pena <jpena(a)redhat.com> wrote:
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.
Cheers,
Jakub
Hi all,
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.
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
well.
- 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
parties.
- Other alternatives?
Attachments:
- attachment.html (text/html — 3.3 KB)