Bug#587377: debian-policy: Decide on arbitrary file/path names limit
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 some arbitrary value, nor should they be like "hey,
> this filename is under the policy defined limit, so there's nothing to
> worry about". Instead, they should try to do what they want to do just
> like they normally would, check for errors like they're already doing,
> and handle themselves as gracefully as possible and give informative
> information based on errno when stuff doesn't work as expected.
Yes, sorry, that was unclear of me. What I meant is that dpkg could
avoid adding suffixes of more than 16 characters to filenames in the
future (and probably should).
> Like I said before, I think having lintian warnings for concrete
> known/potential issues (like this package won't unpack on a CDROM,
> ReiserFS, etc) would be good (really good even), but I don't see where
> the gain is in having arbirary policy-defined limits in packaging. What
> is the benefit of all this?
>
> The only benefit I could think of would be if instead of defining the
> maximum limit, we defined/referenced a minimum guaranteed limit that
> "debian installation compatible" filesystems must support. This might
> then provide a bit of guidance in the situation where install failures
> occurred on some arbitrary filesystem/package/path combination.
Right. The general view seems to be roughly that this belongs in the
realm of unofficial policy / best practices / case law, so I'm going
to go ahead and tag this bug rejected. However, I'll leave it open as
usual for policy bugs, in case someone wants to argue for it.
Secretly I hope that some kind, lintian-knowledgeable person might
glean some advice from it for new checks.
Thanks for your help.
Reply to: