On Thu, Mar 03, 2011 at 04:35:09PM -0600, Jonathan Nieder wrote:
> Bill Allombert wrote:
>
> 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
On Wed, 02 Mar 2011, Sean Finney wrote:
> Having a warning in lintian for arbitrarily long (perhaps >= 256)
> filenames is totally reasonable i'd say, but there's no reason to
Most (all?) filesystems commonly used in Debian systems will limit you to
somewhere close to 254 characters per filename (
Bill Allombert wrote:
> To give an example: Debian policy mandates that the file
> /usr/share/doc//changelog.Debian.gz
> exists.
> Now perl subpolicy mandate that the perl module
> Foo::Bar::Baz::Qux::Quux::Quuux::Qx
> whic live in /usr/share/perl5/Foo/Bar/Baz/Qux/Quux/Quuux/Qx
> be pa
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
tags 587377 + wontfix
quit
Sean Finney wrote:
> On Thu, 2011-03-03 at 15:58 -0600, Jonathan Nieder wrote:
>> * how many characters of grace area can tools like dpkg-divert feel
>>free to use?
>
> I don't think tools should be like "whoa, i think this filename is going
> to be too long" for s
Hi Jonathan,
On Thu, 2011-03-03 at 15:58 -0600, Jonathan Nieder wrote:
> * how many characters of grace area can tools like dpkg-divert feel
>free to use?
I don't think tools should be like "whoa, i think this filename is going
to be too long" for some arbitrary value, nor should they be lik
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
On Thu, Mar 03, 2011 at 03:58:59PM -0600, Jonathan Nieder wrote:
> Bill Allombert wrote:
> > On Wed, Mar 02, 2011 at 10:17:32PM -0600, Jonathan Nieder wrote:
>
> >> Another question: is Debian policy the right place to make a decisions
> >> like this? Ideally these maxima would be set using some
Bill Allombert wrote:
> On Wed, Mar 02, 2011 at 10:17:32PM -0600, Jonathan Nieder wrote:
>> 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
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 dat
On Wed, Mar 2, 2011 at 22:17:32 -0600, Jonathan Nieder wrote:
> If I had to make a proposal, I'd suggest maxima of
>
> _XOPEN_PATH_MAX / 2 (= 512) for paths, to leave room for chroots
> _XOPEN_NAME_MAX - 16 (= 239) for filenames, to leave room for
> .dpkg-divert.tmp. Forget ReiserFS 3. :)
>
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
dpk
u...@debian.org (Aaron M. Ucko) writes:
> (in usr/share/doc/kwwidgets-doc/html), 138 characters long, so such a
That's a pathological example per #552346; disregarding kwwidgets-doc
gets the current limit down to 133, which 14 packages hit in unstable.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.
Jonathan Nieder writes:
> E.g., what filesystem?
As I recall, I was running reiser3 at the time.
> Now I'm starting to worry that it might have been the length of the
> filename rather than the pathname that triggered Bug#587440. But the
> filename was only 234 characters, which should certain
Sean Finney wrote:
> Back when I was doing the conffile stuff I recall seeing hardcoded 256
> character limits within dpkg in the archive handling stuff.
"path_quote_filename(buf, fname, 256)" and %.255s get used to display
filenames to the user, but I think anything lower level having that
limit
hi jonathan,
On Wed, 2011-03-02 at 13:11 -0600, Jonathan Nieder wrote:
> Now that I check, the path provoking this was 269 characters
> (including leading '.'). I'm able to install the package, both on
> tmpfs and ext4, without trouble. I suppose it would be interesting to
> know: what was the e
Sean Finney wrote:
> Having a warning in lintian for arbitrarily long (perhaps >= 256)
> filenames is totally reasonable i'd say, but there's no reason to
> otherwise throw out limits for the sake of having them.
Oh, I don't know.
Now that I check, the path provoking this was 269 characters
(inc
Hi,
I don't think policy really has much place establishing an arbitrary
file limit either, though.
Having a warning in lintian for arbitrarily long (perhaps >= 256)
filenames is totally reasonable i'd say, but there's no reason to
otherwise throw out limits for the sake of having them. It shoul
Jonathan Nieder writes:
> This is a hard one. I agree that dpkg shouldn't enforce this (though
> perhaps it could recover better).
That's fair.
> To throw out a strawman, I suppose 256 characters should be a reasonable
> maximum for paths in Debian packages.
Running a variant of your script (
user debian-pol...@packages.debian.org
usertags 587377 + normative issue
quit
Guillem Jover wrote:
> This is not really a dpkg bug, the limitation is not actually coming
> from it, it's coming from the kernel and/or specific file system
> implementation. I don't consider it appropriate to add an
reassign 587377 debian-policy
retitle 587377 debian-policy: Decide on arbitrary file/path names limit
severity 587377 wishlist
thanks
Hi!
On Sun, 2010-06-27 at 21:03:28 -0400, Aaron M. Ucko wrote:
> Package: dpkg
> Version: 1.15.7.2
> Severity: important
>
> dpkg won't let me install (upgrade to
21 matches
Mail list logo
