[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: .deb format: let's use 0.939, zstd, drop bzip2



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 <ijackson@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.


Reply to: