Open nacl opened 3 years ago
We can do whatever we want. Since there is, so far, 1 method that writes the manifest, and one that decodes an entry, and they are both private interfaces, changing the format is fair game as we need it.
Another reason for moving to that now might be that we may have to add more user/owner types for #370 . Rather than add more fields at the top level, add them to the embedded struct.
One more requirement: We need operators around this
Been thinking about this on and off. Initial thoughts:
type
field (a string or enumerated value). This type dictates how the "core" attributes are interpreted.pkg_rpm
)So, something like this:
[
{
"label": "//:foo-config",
"type": "FILE",
"source": "bazel-out/k8-linux-fastbuild/foo", // or whatever bazel provides us
"destination": "{PREFIX}/etc/foo", // Templated destination
"mode": "rw-r--r--", // or 0644
"user": "root",
"group": "root",
"rpm_filetag": "%config" // Custom attribute for pkg_rpm
"zip_compression": "STORE" // Theoretical custom attribute for pkg_zip
"unix_extended_permissions": "+i" // Theoretical custom attribute for UNIX-style installers (set immutable bit)
},
...
]
This is simple enough to meet all the above requirements and is also relatively futureproof. It also has the unfortunate consequences of requiring more code and redoing a bit of the logic that we already have for the manifest system as used in pkg_zip
and pkg_tar
. WDYT?
I like the idea of the JSON manifest format -- it allows us to create backends for a generic packaging frontends.
I would like to adopt this for
pkg_rpm
at some point, but in order to do this, the manifest would need to support a generic "attributes" format to support file tags (like%config
). This will also be needed for supporting packages in Windows.So, instead of separate
mode
,user
, andgroup
fields, perhaps we should have anattributes
object that can contain arbitrary information, mirroringpkg_attributes
in thepkg_filegroup
framework?