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 via email to