Skip to content

OpenVox Server (RPM) packaging #74

Open

Description

@ekohl

This is to write out my thoughts for the future of OpenVox Server packaging. I'm heavily thinking about RPM here.

I'd love to have equivalents for Debian because then we can get rid of ezbake but I'm less familiar with the options here.

Below I'm listing 3 levels of integration, each building on the previous.

Write a native openvox-server.spec file

Today we use ezbake to wrap FPM, but my intention is to write a real openvox-server.spec file. I think this is easier to maintain and integrate with RPM packaging tooling. It will result in a single SRPM that can be used to build all platforms.

I've started this in OpenVoxProject/openvox-server#61.

Integrate packit for CI and nightly packages

Once there's a native spec file we can use packit to build on every PR and after every merged commit. This means users can try out real RPMs for every PR (if it builds) or run bleeding edge versions.

This relies on coming up with a step that runs something to produce the source tarball and listing the right SRPM build dependencies. https://github.com/theforeman/foremanctl/blob/master/.packit.yml can be used as a starting point.

Packit itself relies on copr to build.

Enable RPM testing using Testing Farm

Packit can also trigger tests in Testing Farm. It relies on tmt. That can probably run beaker on the local machine.

This area I'm the least certain about. It may not provide that much value. Currently Testing Farm doesn't implement multi-machine testing and that may be too limiting for OpenVox Server testing. I still want to mention it though.

Activity

  1. c33s commented on Jul 31, 2025

    @c33s

    as you mentioned fpm i just want to mention nfpm

  2. ekohl commented on Jul 31, 2025

    @ekohl
    Author

    I'll mention that I explicitly want to get rid of the fpm model. You can see that ezbake is a layer that's built because there are many differences between deb and RPM. So many that I think it's not worth it.

    Native packaging gives you so much more and I want to be able to leverage that.

  3. ashish1099 commented on Jan 29, 2026

    @ashish1099

    why can't we use go-release which us nfpm ?
    and the release process is streamlined with a single config file ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions