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

[Jonathan Nieder <jrnieder@gmail.com>]

Bill Allombert wrote:

> Not really;  the packager might not be able to change the filename without breaking either 
> FHS compliance, the interface or compatibility with upstream.

Ah, now I think I understand a bit better.

FHS compliance sounds like a red herring to me.  Does the FHS mandate
anything close to filenames of 239 characters or paths of 512
characters?

Re compatibility with upstream, to the extent that it is not an
interface: it's worth mentioning that as a cost to imposing
requirements, but I do not think it is a good excuse to accept buggy
software.  If we wanted to maintain perfect compatibility with
upstream (and upstream were not cooperative for some reason), many
parts of policy would not apply.  For example, sloppy programs
launching an editor would tend to use vi and not respect $EDITOR.

Now preserving interfaces _does_ seem like an objection that's more
important.  A policy "should" like this (potential) one represents a
bug but it is not necessarily more important than the other bug of
breaking compatibility.  Breaking interfaces can be difficult and it
takes time.  But if that's what it takes to make your path usable
with dpkg-divert (which is what the filename limit is about), that
_definitely_ seems worth it to me; and if that's what it takes to
make your package unpackable on kFreeBSD with a long leading prefix
that also seems worth it.

Perhaps the 512 seems gratuitously low?  How about

 _XOPEN_PATH_MAX - 100 = 924	- for paths
 _XOPEN_NAME_MAX - 16 = 239	- for filenames

?

Jonathan