Bug#587377: debian-policy: Decide on arbitrary file/path names limit
reassign 587377 debian-policy
retitle 587377 debian-policy: Decide on arbitrary file/path names limit
severity 587377 wishlist
thanks
[ Resending to the list, forgot the first time, setting Reply-To to the
bug report. ]
Hi!
On Sun, 2010-06-27 at 21:03:28 -0400, Aaron M. Ucko wrote:
> Package: dpkg
> Version: 1.15.7.2
> Severity: important
>
> dpkg won't let me install (upgrade to) the latest version of sbcl-doc:
>
> Preparing to replace sbcl-doc 1:1.0.34.0-1.1 (using .../sbcl-doc_1%3a1.0.39.0-1_all.deb) ...
> Unpacking replacement sbcl-doc ...
> dpkg: error processing /var/cache/apt/archives/sbcl-doc_1%3a1.0.39.0-1_all.deb (--unpack):
> unable to clean up mess surrounding `./usr/share/doc/sbcl-doc/html/sbcl/Method-sb_002dbsd_002dsockets_003asocket_002dmake_002dstream-_0028_0028socket-socket_0029-_0026key-input-output-_0028element_002dtype-_0027character_0029-_0028buffering-full_0029-_0028external_002dformat-default_0029-tim' before installing another version: File name too long
> dpkg-deb: subprocess paste killed by signal (Broken pipe)
(This error is from dpkg trying to cleanup in case a previous run was
interrupted half-way, which was not the case here, but rename(2)
validates first the arugments so it returns with ENAMETOOLONG instead
of the usual ENOENT or ENOTDIR.)
> I'll mark sbcl-doc as affected, but I'd argue that this is ultimately
> a bug in dpkg for being unable to cope with such long filenames or
> perhaps in dpkg-dev for allowing them into packages; one way or
> another, there should not be skew, particularly in that direction.
This is not really a dpkg bug, the limitation is not actually coming
from it, it's coming from the kernel and/or specific file system
implementation. I don't consider it appropriate to add an arbitrary
limit in dpkg itself, when it can handle long file/path names just
fine.
Given that this might cause problems depending on the different support
from the build and host machines this should be considered a matter of
policy, and as such “enforced” by lintian or ftp-master for example, if
at all. I'm thus reassigning it to debian-policy, so that an arbitrary
limit can be decided if desired.
thanks,
guillem
Reply to: