Re: RFC: Unified package metadata format
Guillem Jover:
> Hi!
>
> On Tue, 2017-03-28 at 16:22:58 -0700, Matthew Garrett wrote:
>> I'm looking at implementing support for IMA file signatures inside
>> dpkg. The previous patches posted for this
>> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850340) did so
>> using extended PAX metadata, but people didn't seem terribly
>> enthusiastic about that.
>> https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking suggested
>> mtree as a potential format, so I thought I'd try to kick off some
>> discussion and see whether I'm missing any requirements or whether
>> there were any better ideas. So:
>
> As mentioned on IRC, I updated the wiki with some more thoughts.
> Regarding PAX, it's my intention to extend and merge those patches
> for 1.19.x, but as stated there, I'm not entirely sure that's the best
> way (currently) to transport that metadata.
>
Glad to see this moving forward. :)
> [...]
>> 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:
>
> ,---
> /set <global-attr…>
> /unset <glonal-attr…>
> .<absolute-pathname> <local-attr…>
> # comment
> <blank-line>
> `---
>
In this variant, can /set and /unset be interleaved between paths? My
previous PoC implementation did this and I was wondering if it would be
supported. :)
> No indented nor continuation lines, no relative paths, no ".." entries.
>
> 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.
>
The "ignore" keyword being something like "anything that matches
/except/ whatever matches the ignore keyword"?
>> [...]
>
>
> My current working plan is to get the last items for 1.18.x out,
> ideally this week or the next. Then immediately branch 1.18.x and open
> 1.19.x on master.
Sounds great (from my PoV). :)
> At which point I'd get the mtree support integrated
> for the db as the first stage, and then we can start pondering about
> how to transport additional metadata in the .deb as the second stage,
> and finally about the templating mode. The last one might be more
> involved as it will most probably require adding support for built-in
> tar packing. But the second stage would allow to already test stuff
> by manually crafting .debs or writing an external helper or tool to
> inject that metadata, so this should allow us to experiment and not
> block on the whole thing being finalized.
>
> Thanks,
> Guillem
>
I still have a debhelper tool to generate the mtree format, which I am
happy to revive. In particular, I would be delighted if that revival
means we can migrate debhelper away from "chown" and just use the format
to describe ownership.
I intend to do an upload of debhelper to experimental later and am happy
to include it there if it would be any help.
Thanks,
~Niels
Reply to: