Re: Problem making large .deb files
Guillem Jover writes ("Re: Problem making large .deb files"):
> Yes, and a known one:
> also mentioned in the format spec:
A friend reports:
16:32 <ewx> largest file in my debian mirror
16:33 <ewx> 1037152 ./pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb
16:34 <ewx> so debian is only a factor of 10 away from the limit
Diziet refers to
This suggests that we should start planning for a transition to
increase this limit, right away.
The wiki suggests three solutions:
* Use some other container format. But this would break detection as
a non-deb format. Painful.
* Bump major version to 3, and split the large ar members into
different tar slices. For example: control.tar.xz, data-1.tar.xz,
* Bump major version to 3, and use an ar container, concatenated
with something else. Non-standard.
I would like to suggest consideration of a fourth:
* Split long tarballs into separate byte streams which
are to be concatenated at read time. For example:
Do this only for .debs where it's needed. There is no need
to bump the major version, as this extension will already be
rejected by existing dpkg's.
This is probably not too hard to retrofit into the dpkg-deb ar parser.
Manipulating (and creating) such archives by hand can be done with cat
Doing this (with the longest possible suffix) for data.tar.xz will
cope with up to data.tar.xz+zzzz, improving the limit by a factor of
26^4 for a maximum file length of 4569759999543024 bytes (4.6 E15
bytes or 4156Tb).
If more is wanted, or additional longer compression names are wanted,
`data' could be replaced by `d'.
Because the control.tar.gz filename is longer, it provides only an
additional factor of 26, up to control.tar.gz+z (259 E9 bytes or
242 Gb). But is anyone anywhere near the limit for control archives ?
It seems likely that there are other problems with gigantic control
If more headroom is wanted, `control' could be replaced by `c'.