Re: Status of deb(5) format support in Debian
Hi!
On Thu, 2013-08-01 at 09:38:35 +0100, Neil Williams wrote:
> On Wed, 31 Jul 2013 18:24:32 +0200
> Guillem Jover <guillem@debian.org> wrote:
> > Due to bug 718295, and in preparation to add non-gzip compression
> > support for control.tar, I've tried to get an accurate view of the
> > current deb(5) format support in software present in Debian. The
> > resulting table looks pretty bad:
> >
> > <https://wiki.debian.org/Teams/Dpkg/DebSupport>
> Can you clarify the LFS column please Guillem?
LFS in the .deb context means being able to handle packages > 4 GiB,
the limiting factor there is the bare ar container which allows at
most members of around 9.3 GiB each. The next limit comes from tar
allowing file entries of at most 8 GiB.
The main reasons for lack of LFS are usage of non-64-bit types when
handling file offsets or sizes on 32-bit systems and mmap(2)ing or
slurping large files into memory (which might not fit even on a
64-bit system).
> How were the packages tested for this support and what are the criteria?
Sorry, should have mentioned that on my mail or on the wiki page. I've
not tested any of the software there (except for previous tests of dpkg
and ar :), I did the table with just code staring.
In your case (deb-gview I guess), there's several problems, one stems
from (AFAICS) slurping file entries from the data.tar, another in case
the debian-binary or control.tar.gz members are > 4 GiB (usage of
strtoul() to parse the ar member size), although these could be
considered corner cases, also if there's a large _-style member before
the control.tar or data.tar members (which would not be skipped correctly
anyway), the ar header would be parsed incorrectly. But the analysis
might be wrong, you might be able to use the package generated for
testing in the dpkg pkg-tests.git t-lfs test case as a starting point:
<http://anonscm.debian.org/gitweb/?p=dpkg/pkg-tests.git>
Thanks,
Guillem
Reply to: