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