On Sat, Mar 26, 2011 at 08:56:14AM +0100, Raphael Hertzog wrote: >On Fri, 25 Mar 2011, Steve McIntyre wrote: >> On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote: >> >Steve McIntyre wrote: >> >> There are uses I've heard about, including (apparently quite common) >> >> using CDs and DVDs to seed a mirror on a Windows server. >> > >> >If I had to chose between that working, and not needing to worry about >> >filename lengths, I'd choose the latter. >> >> We already have arbitrary limits on filename length (~200 bytes or so >> on RockRidge), even before this. I'm just proposing to lower them for >> a common use case. Do we really care about supporting *very* long >> names here? > >I think so. The package with long names tend to follow a naming policy >that sort of imposes the long name... so if we put a too-short limit >then we're asking them to make an exception in the naming policy.
So what's a reasonable name length limit then? 80? 150? 2000? >> >One approach then would be to omit joliet filenames for the few long >> >packages. This would not even impact your use case above much, since >> >any mirror seeded from files from CDs needs a further sync step. >> >> I'd be much happier to not have to special case yet another thing in >> the CD scripts. That way potentially leads to unforeseen bugs in the >> future, for very little gain. > >What happens if you try to put too-long filenames on the CD with Joliet >enabled? > >Does it fail to build? Are there options to rename the files >automatically? It will fail to build. I don't want to rename the files, I'd like to get some agreement on how to fix the problem properly. >If it means we have some unexpected filenames for long filenames on >Windows, it's not a big deal IMO. For people who may want to verify the files on their CDs it might be. -- Steve McIntyre, Cambridge, UK. st...@einval.com Is there anybody out there? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330105139.gg7...@einval.com