Re: RFC: Unified package metadata format
Matthew Garrett wrote:
> Debian package unified metadata format
In general, this looks like a good idea. Having this in a declarative
form would have a variety of good uses.
> The file shall be stored within the control archive with the name
> “mtree” and shall start with the following string:
> #mtree v2.0
> Each entry shall be of the form
> /path/name key1=foo key2=bar
> Ie, a leading space, a slash, and the path name of the installed file
> followed by a series of space-separated key=value pairs followed by a
> line feed. The following keys are supported (extracted from mtree(5)):
I'd assume that some of the quirks, like the leading space, come from
the original mtree format?
What escaping mechanisms exist for filenames containing spaces? Or
At least the former *does* exist in Debian. And I could imagine the
latter existing in packaged testsuite data.
> * md5 - the MD5 message digest of the file
> * md5digest - a synonym for md5
> * sha1 - the FIPS 160-1 (“SHA-1”) message digest of the file
> * sha1digest - a synonym for sha1
> * sha256 - the FIPS 180-2 (“SHA-256”) message digest of the file
> * sha256digest - a synonym for sha256
Backward compatibility with existing mtree implementations aside, any
reason a new standard for using mtree in package metadata should allow
md5 or sha1 at all?
> * Are any other keys required? Should dpkg-divert be implemented using
> this format?
I'd love to see things like alternatives implemented declaratively using
this format; doesn't seem that hard to add keys like
(as well as "alternative.parent" or similar to use on manpages that
should switch with their parent application).
But at the same time, I'd suggest getting to a baseline implementation
with a minimum of bikeshedding, and then slowly moving other things