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.
> Format: > > 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 newlines? 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 alternative.name=vi alternative.priority=... (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 over.