Bug#587377: debian-policy: Decide on arbitrary file/path names limit
On Wed, Mar 02, 2011 at 10:17:32PM -0600, Jonathan Nieder wrote:
> 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:
I do not think it is the purpose of Debian policy to limit file name and path
length without providing guidance.
Most of the time, files path are not chosen by the packager, but are functionnal
elements imposed by external considerations (compatibility with upstream,
compliance with the FHS/Debian policy, required by an external interface, etc.).
For example, an interface can store a data structure as a directory hierarchy.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: