Consider using RPM spec with debbuild for creating Debian packages

[Conan-Kudo]

I’ve heard you folks are working on trying to make it easier to quickly produce RPM and Debian packages… Have any of you folks heard of debbuild?

With this tool, you can use a singular RPM spec file to build both RPM packages with rpmbuild and Debian packages with debbuild. Combined with the debbuild-macros package, it’s quite a bit easier to make RPM spec files leveraging the same macros as they would in RH/Fedora work for building Debian/Ubuntu packages.

As an example, I packaged safe (a Hashicorp Vault client) for Fedora and Ubuntu using this technique on the openSUSE Build Service. You can see the spec file showing how simple the packaging can be.

This allows you to use the same spec for building across RPM and Debian distributions, which should simplify handling releasing native packages for Kubernetes.

[idealhack]

/sig release
/area release-eng

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[Conan-Kudo]

😢

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[Conan-Kudo]

😭

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[justaugustus]

@Conan-Kudo -- Thanks for submitting this and our sincere apologies for not getting you a response sooner.

At this time, we're not planning to bring debbuild into our workflow.
A few things that we need to ensure during the artifact creation/publishing process:

1. intermediate artifacts (like the deb/rpm specs) are produced in a native format
2. we have control over all of the tools in the process

For 1, consumers of kubepkg will expect a native Debian package definitions or rpm specs. Anything else means downstream consumers will need to change their workflows to accept a debbuild format, leading to 2... if we don't primarily control the format, we can't officially support it.

[Conan-Kudo]

we have control over all of the tools in the process

Aside from kubepkg, I'm not sure what else is involved in this process to produce rpms and debs.

For 1, consumers of kubepkg will expect a native Debian package definitions or rpm specs. Anything else means downstream consumers will need to change their workflows to accept a debbuild format, leading to 2... if we don't primarily control the format, we can't officially support it.

What the heck does this mean? kubepkg understands rpm specs, which is basically enough for debbuild. That's all it uses. It just needs to push spec files that have the couple of extra fields required for Debian packages that map to Debian control fields and that's it. You replace rpmbuild with debbuild and it works the same way...