Bug#26431: dpkg: --build/--install conflict with long pathnames
Package: dpkg
Version: 1.4.0.23.2
I made a local package (a deep hierachy of HTML documents) and packaged
it successfully using 'dpkg --build'.
When I came to install it I got this:
danae:# dpkg --install helpme-0.0.6_X.deb
(Reading database ... 22272 files and directories currently installed.)
Unpacking helpme (from helpme-0.0.6_X.deb) ...
dpkg: error processing helpme-0.0.6_X.deb (--install):
corrupted filesystem tarfile - corrupted package archive
Errors were encountered while processing:
helpme-0.0.6_X.deb
I looked this up in the GNU tar 'info' files, and see that traditional
tar commands have a limit of 100 chars on a pathname. GNU tar uses
various devious means to exceed this while still keeping within the tar
format standard.
[ One means is something about '@LongLink' (see info pages) which I do indeed
witness is used; in tarring the whole structure from directory to another I
encounter the message:
tar: ././@LongLink
but the tar stream arrives uncorrupted and without warnings or errors, so
GNU tar handles it fine. ]
I don't know anything about the internals of dpkg, but it seems to be
behaving as if GNU tar is used to --build the .deb file, and then a
non-GNU tar is used to --install it.
I can't find documented anywhere that dpkg has any limits, and certainly
when I build the .deb file, dpkg gives no warnings or errors.
FYI, the longest path in the hierachy is 105 characters:
/usr/local/opt/helpme/doc/helpme/linux-sysadmin-tasks/software-management/installing-debian-packages.html
If I can be of any assistance then please email me.
Regards
Alexis
-- System Information
Debian Release: 2.0
Kernel Version: Linux danae 2.1.115 #2 SMP Sat Aug 22 17:08:29 BST 1998 i486 unknown
Versions of the packages dpkg depends on:
ii libc6 2.0.7t-1 The GNU C library version 2 (run-time files)
ii libstdc++2.8 2.90.29-0.6 The GNU stdc++ library (egcs version)
ii ncurses3.4 1.9.9g-8.8 Video terminal manipulation - shared librari
Reply to: