Bug#587377: debian-policy: Decide on arbitrary file/path names limit
On Thu, Mar 03, 2011 at 04:35:09PM -0600, Jonathan Nieder wrote:
> 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?
To give an example: Debian policy mandates that the file
/usr/share/doc/<package>/changelog.Debian.gz
exists.
Now perl subpolicy mandate that the perl module Foo::Bar::Baz::Qux::Quux::Quuux::Quuuux
whic live in /usr/share/perl5/Foo/Bar/Baz/Qux/Quux/Quuux/Quuuux
be packaged as
libfoo-bar-baz-qux-quux-quuux-quuuux-perl,
which leads to the file
/usr/share/doc/libfoo-bar-baz-qux-quux-quuux-quuuux-perl/changelog.Debian.gz
> 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
I am not objecting to a limit being set. What I am objecting to is for policy to forbid
something without providing guidance on how to deal with the issue.
If you look at the section about software version, policy provides guidance how to deal
with software without upstream version or non-increasing upstream version, it does not
just state that this is forbidden, etc.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: