Re: RFC: Unified package metadata format
Hi!
On Tue, 2017-04-04 at 07:20:00 +0000, Niels Thykier wrote:
> Guillem Jover:
> > 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. :)
Yes, like in the common mtree(5) format theese commands can be
interleaved, so you can set or unset defaults for the next entries.
> > 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"?
The keyword is described in the man page as:
"Ignore any file hierarchy below this file."
> > 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.
> 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.
See the updates I mentioned to the wiki; something I realized while
pondering a bit more about all this, is that we cannot safely only
ship the user/group information in the mtree files (and not in the
tar entry) as then older dpkg would be unable to set the correct owner
and permissions. So the mtree shipped would only contain information
not already present in the tar entry.
Regards,
Guillem
Reply to: