rules_pkg
rules_pkg copied to clipboard
bazelbuild
SRPMs and mock feature request
It'd be useful (to us) to generate the Source RPM (SRPM) with rpmbuild -bs separately to the binary RPM.
This would allow us to use mock as a wrapper around rpmbuild bb to build against several different chroots. mock only supports building an RPM with an SRPM.
This allows for us to build an RPM with the matching rpmbuild version for an OS that cannot run bazel itself.
Generally, SRPMs being built from rules_pkg is an aspirational thing due to lack of interest, but I've thought about it from time to time.I'm curious -- what do you imagine the spec file would look like for a bazel-built SRPM?
My understanding is that a "proper" source rpm would contain something that would require running Bazel, with pkg_install being used for staging purposes.
I experimented with this a while ago (outside of bazel, with buck actually).
TL;DR: Same spec file, but it includes %sources and %build stanzas.
At that time I was trying to build a .so and have it linked correctly for CentOS6/8 using mock's chroots.
Broadly the SRPM contained SPECS/* and SOURCES/* which comprised everything that mock would need to build.
In a bazel-like case, pkg_rpm would generate foo.srpm with rpmbuild -bs containing SPECS/foo.spec and SOURCES/foo0.tar.gz, SOURCES/foo1.tar.gz or similar, where the SOURCES/* are everything from the srcs attribute.
The spec file is pretty much the same except it now needs a %build stanza, which would need to be "self-contained" as such to what tooling is available in the mock chroot (probably nothing to do with bazel!)
It's a bit unpleasant TBH.
I've also tested with a docker/container based approach, with a wrapper script that delegates to a docker container rpmbuild.
I think a fundamental problem with source RPMS is that they only make sense in the context of having an RPM based system, where the dependencies are all installed, rather than declared in the WORKSPACE. Another way to think about that is that if you can build from a source RPM, your system must be laid out in a very particular way so that things just build. But then why do you need Bazel?
A hermetic RPM is very difficult. It relies on macros and definitions in /usr/lib/rpm/macros.d for example.
I haven't figured out how to get a chroot for the right distributions working yet.
Yes, hermetic source RPM would be really difficult. I think it's a fundamental problem of trying to know to build in either the source RPM way or the source Debbie impacted way versus bazal. I mean RPM and Debian and believe that you should use what's installed in the environment because we fully control the environment and basal believes don't use what you find in the environment because you don't control it. So I mean the two are just philosophically at odds.
On Thu, Feb 16, 2023, 3:45 PM Nick Breen @.***> wrote:
A hermetic RPM is very difficult. It relies on macros and definitions in /usr/lib/rpm/macros.d for example.
I haven't figured out how to get a chroot for the right distributions working yet.
— Reply to this email directly, view it on GitHub https://github.com/bazelbuild/rules_pkg/issues/673#issuecomment-1433621983, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXHHHH3P2WOLUF75NOQUOLWXZ7WZANCNFSM6AAAAAAU27SZAE . You are receiving this because you commented.Message ID: @.***>