On Mon, Apr 3, 2017 at 6:58 PM, Guillem Jover <guil...@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!