rpm, deb (maybe tar and zip) rules should be a new rule repo, not part of Bazel
aiuto opened this issue · 11 comments
The rules for building distribution packages have no need to be part of Bazel. They should be owned by the people who most need them.
Proposal: https://docs.google.com/document/d/1GAbAiW0nVbxGlwsdXhFIcn3owlZJkMJiXBt-ttA9z_k/edit#
TL;DR:
- we will move the rules to a new repo
- bazel team will continue to review PRs for a while
- if you start making hight quality contributions we'll give you merge rights
I'm more than happy to see these rules added in https://github.com/bazelbuild/rules_pkg (and I don't think a different repo should be created), if anyone is interested I can explain why that repo exists and what was the initial goal there.
rules_pkg is currently about fetching rpms rather than building them. So the concerns are actually different. That said, I am also not against having one repo provide both rules for using and building. That would allow a small set of people to understand both sides of the process to own the work.
I strongly agree that the rules for building packages should be moved out of the core repo. Making improvements to these rules has been challenging, since they're linked to bazel releases; breaking changes are especially problematic.
I also agree that rules_pkg seems like the right place. I was surprised when I discovered rules_pkg had nothing to do with building packages.
I'll leave this to age for a week so the rest of the community can chime in.
Unless I am convinced otherwise, I will start committing PRs on June 5 to move the code out.
- The first round will just be to make it available.
- The second round is to stop taking PRs against the internal Bazel code
- The third is to move Bazel over to the new repo. The choices there belong to @philwo
FYI: @apt-itude @vmax @tmc @beasleyr-vmw @EdSchouten @ltekieli @gertvdijk @ash2k @roblg @XindaH @c4urself @mmikitka @pawelz @philsc
+1 to have them in a separate repo. For remote execution, the pkg_rpm rule is currently problematic as it expects rpmbuild to be installed in the exec environment. These rules should ideally use toolchain rules to define their tool dependencies and to ideally be made compatible with remot exec. Doing this would be much easier if they are in their own repo.
fyi @agoulti
rules_pkg is currently about fetching rpms rather than building them. So the concerns are actually different.
I know, I wrote them. ;-)
My hopes were from the beginning that the existing ones get ported from bazel/bazel to bazel/pkg_rules eventually, but that requires some coordination effort, as you can see - so I only put in the fetching instead of copying over also the building rules initially.
It might be worth looking over the package building rules by the way to see if they could be improved (pkg_rpm is for example a very thin wrapper around rpmbuild and barely more than a shell script) so they also work on other platforms like Windows. After all, they are little more than compressed tarballs with a certain internal structure and some metadata files.
Agree, a recent break in make_deb.py has me wishing for a git_repository and commit to point to to keep things stable.
@aiuto
Happy to help in any way I can, particularly wrt how to define a toolchain that will pull the tools needed for pkg_rpm so that it works with remote exec
as for rules_docker, iirc, we do support pkg_deb in rules_docker, pkg_rpm, I think, is not currently supported for rules_docker (but should not be hard to add, we just haven't had the request from users to do this yet).
I am pleased to announce an initial release of the decoupled pkg_{deb, rpm, tar} rules.
https://github.com/bazelbuild/rules_pkg/releases/tag/0.1.0
With that, I am closing this issue. Future issues and PRs should be against that repository. Go forth and innovate.