Bug#587377: debian-policy: Decide on arbitrary file/path names limit

[Jonathan Nieder <jrnieder@gmail.com>]

Aaron M. Ucko wrote:

> As I recall, I was running reiser3 at the time.

Thanks.  To summarize:

A lintian-clean Debian package failed to unpack with ENAMETOOLONG.
Setting maximum lengths for paths and filenames in data.tar.gz
in policy could prevent future mistakes of this kind, without making
dpkg itself any less flexible.

Packages currently are not using paths of more than 255 characters.
kFreeBSD uses a PATH_MAX of 1024 (and Linux 4096), so this seems safe,
even with the possibility of .dpkg-dist suffixes and
/var/complicated/path/to/chroot prefixes.  Making it a hard limit
would allow dpkg-managed files to be archived using non-GNU tar and
similarly limited tools.  Not so interesting.

Packages currently are not using filenames of more than 150 characters.
This is cutting it close for unpacking on ISO9660 cd-roms (~180 chars
max).  Is that use case worth worrying about?  The only other
filesystem of concern is ReiserFS 3, which does not support filenames
of longer than 226 characters.  A maximum of 175 or 200 characters
would leave 16 chars for ".dpkg-divert.tmp" and a little extra grace
area, hopefully addressing all practical problems.

Another question: is Debian policy the right place to make a decisions
like this?  Ideally these maxima would be set using some cross-distro
standard like POSIX or the FHS.  Sadly:

 - the FHS has nothing to say about lengths;
 - POSIX only allows 14 characters, which is not enough;
 - XSI allows 255 characters, which is appealing but more than
   ReiserFS 3 can handle.

If I had to make a proposal, I'd suggest maxima of

 _XOPEN_PATH_MAX / 2 (= 512) for paths, to leave room for chroots
 _XOPEN_NAME_MAX - 16 (= 239) for filenames, to leave room for
 .dpkg-divert.tmp.  Forget ReiserFS 3. :)

I imagine others may have better ideas.

Hope that helps,
Jonathan