Adam Borowski writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> It's not possible to peel away the outer layer as tar doesn't guarantee the
> data is contiguous in the file. It supports sparse files, etc.
If we were to use tar as a format we would support only a restricted
subset of tar, obviously. For comparison, we don't support anywhere
near all `ar' formats, to the point that it is awkward to *create* a
legal .deb with a normal ar utility. I think that is OK.
The advantages of my multi-ar-members-for-large-data-file proposal,
over switching to tar:
* recognised as a .deb by all existing sniffing tools etc.
* only .debs with large data files are incompatible with
old dpkg-deb
* given a .deb with large data files, if you don't need the
data archive old tools will still work (dpkg -I, say).
* reduced code churn
The disadvantages are:
* Somewhat increased complexity in .deb decoding software
I think the increased complexity is worth these other benefits.
I was surprised to see people saying that they were still unpacking
.debs occasionally with ar. I guess my decision back in 199mumble is
vindicated... That definitely means we should keep the property that
a .deb can be unpacked with non-Debian-specific shell tools.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
