4:48 a.m.
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:
- Only get involved in the tooling side, if we have no plans to reuse the spec templates
in the future.
- Try a deeper integration with the specs.
- Other alternatives?
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.
Please contribute to the discussion on this thread. We will vote for a final decision
during the next RDO Community meeting on September 5th.
Thanks,
Javier
[1] - https://github.com/openstack/rpm-packaging
[2] - https://github.com/openstack/pymod2pkg
[3] - https://github.com/openstack/renderspec
5:06 a.m.
On Thu, Aug 30, 2018 at 5:48 AM Javier Pena <jpena(a)redhat.com> wrote:
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:
- Only get involved in the tooling side, if we have no plans to reuse the spec templates
in the future.
- Try a deeper integration with the specs.
- Other alternatives?
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.
Please contribute to the discussion on this thread. We will vote for a final decision
during the next RDO Community meeting on September 5th.
I suspect the reason that we haven't been able to leverage the
OpenStack spec templates is because they're based on SUSE's Python
"singlespec" system.
This model of generating flavor subpackages as OpenStack and SUSE
Python packages is rather nice, and I've wanted to bring it to Fedora
as well[1]. Though people were interested in the idea, no one
particularly stepped up to help support exploring the endeavor, which
implied to me that we'd rather spin our wheels around with complex
migration paths as we're doing now for the Python 2 -> Python 3
transition.
If RDO is the driver that pushes us to properly explore this, I'm all
for it. I want our packaging of stuff to get simpler, not harder. And
overall, singlespec is actually a lot simpler for people than what we
do now.
As a whole, I'd rather see us sharing more package specs than not,
since the number of components necessary to package huge systems is
growing, and it's not worth it to spin our wheels over and over.
[1]:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
--
真実はいつも一つ！/ Always, there's only one truth!
11:06 a.m.
Hey,
On Thu, Aug 30, 2018 at 12:06 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Thu, Aug 30, 2018 at 5:48 AM Javier Pena <jpena(a)redhat.com>
wrote:
>
> 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:
>
> - Only get involved in the tooling side, if we have no plans to reuse
the spec templates in the future.
> - Try a deeper integration with the specs.
> - Other alternatives?
>
> 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.
>
> Please contribute to the discussion on this thread. We will vote for a
final decision during the next RDO Community meeting on September 5th.
>
I suspect the reason that we haven't been able to leverage the
OpenStack spec templates is because they're based on SUSE's Python
"singlespec" system.
This model of generating flavor subpackages as OpenStack and SUSE
Python packages is rather nice, and I've wanted to bring it to
Fedora
as well[1]. Though people were interested in the idea, no one
particularly stepped up to help support exploring the endeavor, which
implied to me that we'd rather spin our wheels around with complex
migration paths as we're doing now for the Python 2 -> Python 3
transition.
Can't resist a little rant here... I'm not at all happy with how the py2 ->
py3 migration was solved in Fedora. Debian has multi-pyhon support for like
a decade where py sources are simply compiled to all compatible python
versions you have installed. suse has singlespec. Fedora's approach is
brute force and not generic at all. So I'm all in favor to actually
introducing some order to the chaos, it's worth a try.
If RDO is the driver that pushes us to properly explore this, I'm all
for it. I want our packaging of stuff to get simpler, not harder.
And
overall, singlespec is actually a lot simpler for people than what we
do now.
Fully agreed. Who doesn't like making things simpler? singlespec seems like
a better alternative to current state of things so I say let's use it
unless there's a good reason not to.
As a whole, I'd rather see us sharing more package specs than
not,
since the number of components necessary to package huge systems is
growing, and it's not worth it to spin our wheels over and over.
[1]: https://lists.fedoraproject.org/archives/list/python-
devel(a)lists.fedoraproject.org/thread/2LTMADP3HPV6EC7OU3M5FWHGJNXJ4XAT/
Also fully agreed. We want to leverage the incredible superpowers of human
cooperation to make packaging simpler and increasingly more automated.
Having more consumers for any software makes it more generic, robust,
reusable and also easier to maintain and extend. Packaging is such an
obsucre discipline that we can't afford to duplicate effort, there's too
few of us and too many things to package :)
Cheers,
Jakub
10:47 a.m.
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?
2084
days inactive
2090
days old
3 comments
3 participants
participants (3)
-
Jakub Ruzicka -
Javier Pena -
Neal Gompa