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.
> 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.
Reply to: