Re: RFC: Unified package metadata format
On Mon, Apr 3, 2017 at 6:58 PM, Guillem Jover <guillem@debian.org> wrote:
> On Tue, 2017-03-28 at 16:22:58 -0700, Matthew Garrett wrote:
>> 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. […]
>
> I don't think this is correct. Initial whitespace gets ignored (this is
> not clear from mtree(5), but that's what the various implementations do).
> The subset of type of lines I'm intending to support would be:
Ah, using a leading space means you can start a full path with /
without it being interpreted as a special command. Just starting with
a . instead seems reasonable.
> Then, my idea would be to further distinguish two types of mtree files,
> template and detailed. The first would allow the globs permitted in the
> spec ('[', ']', '?', '*'), and possibly also the "ignore" keyword. The
> second would not. Template mtree would be used in source packages, and
> would be used to generate the data.tar in the .deb and possibly part of
> the detailed mtree in the control.tar, and of course the detailed mtree
> in the db.
Ok, that makes sense. dpkg would never need to know anything about the
template files, then?
>> […] The following keys are supported (extracted from mtree(5)):
>>
>> * md5digest - a synonym for md5
>> * sha1digest - a synonym for sha1
>> * sha256digest - a synonym for sha256
>
> On my WIP code, I've ignored these keywords, because they are just too
> verbose, and I don't the see point with them. We are going to be
> incompatible anyway with standard mtree(5), so… :)
Fair enough.
> I've also got "contents" to represent hardlinks, "time", "ignore" and
> "optional" (but a "class" might make more sense, to be able to specify
> the file as "class=conffile" or "log", "otional/ghost" and similar.
> There's also "nlink" which I should probably drop as it does not make
> much sense for dpkg's purposes.
Makes sense.
>> The following keys are supported but not present in mtree(5):
>> * major - the major number of a device node
>> * minor - the minor number of a device node
>
> Actually some implementations define a "device" keyword, but it seems
> a bit of a mess, given that the major/minor within are OS specific
> anyway. So, my thinking was to probably ignore this one.
If debs can contain device nodes then it feels like we should probably
have a mechanism for verifying whether the ones on disk match the ones
that were in the package?
>> * override.* - if present, will override the contents of a key
>> applying to the same file. This may be used to apply local system
>> policy and must not be present in shipped files.
>
> I'm not sure I see the use for this?
If there were a single mtree that was an authoritative source of
truth, we'd presumably want both the original data and any data that's
been modified by dpkg-statoverride. If we keep a separate statoverride
file then this isn't necessary.
>> * Are any other keys required? Should dpkg-divert be implemented using
>> this format?
>
> Hmm not sure, did you really mean dpkg-divert and not
> dpkg-statoverrides?
No, I meant divert here - if the idea is to be able to parse the mtree
and compare it to the filesystem, some mechanism to indicate when the
user has used dpkg-divert seems helpful.
Otherwise this sounds good!
Reply to: