-
Notifications
You must be signed in to change notification settings - Fork 198
Description
The implementation of the pkg_filegroup
framework relies upon users specifying specifically where files end up in packages. It is up to the user to create the various pkg_files
rules to manage this. This is great for general-purpose use, but can be quite verbose.
One idea for reducing verbosity is to specify package contents in terms of tables, like in #238. That, however, still relies on manual path construction and placement. Another way to specify this is to identify files in terms of their roles, namely what they're intended to do: e.g. configuration files might be installed in one location, binaries another, and libraries another from that.
We can imagine a system by which could associate a "role" with a particular target or target outputs. For example:
cc_binary(
name = "binary",
srcs = [...],
tags = ["role-binary"],
)
cc_binary(
name = "support-binary",
srcs = [...],
tags = ["role-support-binary"],
)
cc_binary(
name = "library",
srcs = [...],
tags = ["role-library"],
)
pkg_role(
name = "role-binary",
prefix = "/usr/bin",
identifiers = ["role-binary"],
)
pkg_role(
name = "role-support-binary",
prefix = "/usr/libexec/foo",
identifiers = ["role-support-binary"],
)
pkg_role(
name = "role-library",
prefix = "/usr/lib",
identifiers = ["role-library"],
)
pkg_role_filegroup(
name = "installed-data",
srcs = [
":binary",
":support-binary",
":library",
],
roles = [
":role-binary",
":role-support-binary",
":role-library",
],
)
pkg_rpm(
name = "rpm",
srcs = [":installed-data"],
...
)
pkg_role
would emit a provider that would inform pkg_role_filegroup
about the nature of a role, in this case, where files end up, and what identifier (tag
) should be used to inspect them. This information would be accumulated in an aspect and then processed to form a PackageFilegroupInfo
provider that can then be passed to packaging rules as needed.
This simplifies the package implementaiton process by allowing users to associate packaging information with the rules that emit the outputs in question, at the cost of granular control. Information regarding destinations and other policies could be encoded into pkg_role
s by way of select
s and other logic.
This also comes with the cost of complex implementation, testing. There are a considerable number of edge cases that would need to be considered, as well as distribution (e.g. roles should be standardized) . Should this feature be desired, a design document should be created, along with prototypes.