Skip to content

RFC: role-based packaging system #402

@nacl

Description

@nacl

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_roles by way of selects 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3An issue that we are not working on but will review quarterlyfeature-request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions