bazelbuild / rules_pkg

Bazel rules for creating packages of many types (zip, tar, deb, rpm, ...)
Apache License 2.0
217 stars 174 forks source link

feature request: build rpms without rpmbuild #662

Closed adam-azarchs closed 1 year ago

adam-azarchs commented 1 year ago

It would be nice to be able to build rpms on systems which don't have rpmbuild installed (e.g. a debian-based build machine). At the very least, supporting rpmbuild as a label would be nice, so one could download it or build it from source. But for many simple cases, rpmpack could be used instead (their readme includes instructions for doing this with tar2rpm, but that is arguably inefficient compared to a more direct approach, and it would be nice to have a more unified API for building .deb and .rpm together, including for example having support for version_file).

nacl commented 1 year ago

I'm hesitant to support this (and @aiuto can answer more authoritatively), but to answer some of your points:

At the very least, supporting rpmbuild as a label would be nice, so one could download it or build it from source.

rpmbuild can be specified as a toolchain today. We use this functionality frequently (https://github.com/bazelbuild/rules_pkg/pull/254) to use a custom-built rpmbuild setup independent of the host OS. You can find more information about toolchains here if you didn't already know.

Also FWIW, there are Debian packages for the RPM tooling available, at least for Debian itself.

But for many simple cases, rpmpack could be used instead

While there plenty of reasons not to use rpmbuild (your points and the inconveniences mentioned in https://github.com/bazelbuild/rules_pkg/issues/661 among them), the main thing that rpmbuild does provide is compatibility. Empirically, RPM packages don't really conform to a specification other than what rpmbuild happens to produce.

...and it would be nice to have a more unified API for building .deb and .rpm together, including for example having support for version_file

This is a separate feature, IMO to be tracked separately. FWIW, it should be relatively easy to implement this if you are interested.

aiuto commented 1 year ago

Empirically, RPM packages don't really conform to a specification other than what rpmbuild happens to produce.

Bingo! That's what makes this hard to support. Any replacement is subject to the problem of tracking rpmbuild changes. What might work is an optional module (bzlmod extension) that adds a dependency on rpmpack (and thus go) along with a BUILD file for that, and a rule that uses it. This, of course, could also be in a distinct project. I'm not inclined to take a dependency on Go as the default.

aiuto commented 1 year ago

Closing to reduce clutter.