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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org