Re: MBF alert: packages with very long source / .deb filenames
Hi, On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre st...@einval.com wrote: If we really want to meet the spec, we should be aiming for 64 characters, but that affects 98 packages and I'm not *too* bothered about it since testing shows no issues thus far. I'm tempted to file: * serious bugs on the packages over 90 characters * normal bugs on those over 80 * wishlist bugs on those over 64 Thoughts? just a shot into the dark: Would it be feasible, or at least possible, to file bug reports with upstream to have the permissible length of filenames officially extended? I mean, everyone has started to use long file names, haven't they? Kind regards, --Toni++ -- 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/20110410171942.19993.qm...@oak.oeko.net
Re: MBF alert: packages with very long source / .deb filenames
On Sunday 10 April 2011 20:19:42 Toni Mueller wrote: Hi, On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre st...@einval.com wrote: If we really want to meet the spec, we should be aiming for 64 characters, but that affects 98 packages and I'm not *too* bothered about it since testing shows no issues thus far. I'm tempted to file: * serious bugs on the packages over 90 characters * normal bugs on those over 80 * wishlist bugs on those over 64 Thoughts? just a shot into the dark: Would it be feasible, or at least possible, to file bug reports with upstream to have the permissible length of filenames officially extended? I mean, everyone has started to use long file names, haven't they? JFTR: xorriso 1.0.6, (with accompanying underling libburnia libraries) was released yesterday, and hit sid some ten hours ago, features: -compliance rule (yes, these are options to deviate from the standard) joliet_long_names Joliet leaf names up to 103 unicode characters rather than 64. joliet_long_paths Joliet paths longer than 240 characters. long_paths allows ISO file paths longer than 255 characters. ... -as mkisofs -joliet-long (sorry in case of email brokeness, on the road-webmail) -- 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/046b852c422d8c7532a7ccd4dc4e1...@spnet.net
Re: MBF alert: packages with very long source / .deb filenames
Goswin von Brederlow goswin-...@web.de Sun, April 3, 2011 5:17:06 PM Philipp Kern tr...@philkern.de writes: On 2011-04-03, Wouter Verhelst wou...@debian.org wrote: OTOH, do you really want to type apt-get install package-with-policy-compliant-utterly-long-silly-name? There's a point when package name lengths become problematic, and that isn't just true for ISO images. That's why $DEITY invented tab completion. (And yes, that really auto-completes on a stock Squeeze install.) Also those long names are usualy installed as part of dependencies so you never type them. outta site! outta mind ! ... there's more to the pizza than just the pie - hey hey my my unknown -- 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/185013.66870...@web35606.mail.mud.yahoo.com
Re: MBF alert: packages with very long source / .deb filenames
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. Yes. OTOH, do you really want to type apt-get install package-with-policy-compliant-utterly-long-silly-name? There's a point when package name lengths become problematic, and that isn't just true for ISO images. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20110403184851.gb9...@celtic.nixsys.be
Re: MBF alert: packages with very long source / .deb filenames
On 2011-04-03, Wouter Verhelst wou...@debian.org wrote: OTOH, do you really want to type apt-get install package-with-policy-compliant-utterly-long-silly-name? There's a point when package name lengths become problematic, and that isn't just true for ISO images. That's why $DEITY invented tab completion. (And yes, that really auto-completes on a stock Squeeze install.) Kind regards Philipp Kern -- 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/slrniphjq3.as3.tr...@kelgar.0x539.de
Re: MBF alert: packages with very long source / .deb filenames
Philipp Kern tr...@philkern.de writes: On 2011-04-03, Wouter Verhelst wou...@debian.org wrote: OTOH, do you really want to type apt-get install package-with-policy-compliant-utterly-long-silly-name? There's a point when package name lengths become problematic, and that isn't just true for ISO images. That's why $DEITY invented tab completion. (And yes, that really auto-completes on a stock Squeeze install.) Kind regards Philipp Kern Also those long names are usualy installed as part of dependencies so you never type them. MfG Goswin -- 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/87lizravcd.fsf@frosties.localnet
Re: MBF alert: packages with very long source / .deb filenames
On Wed, Mar 30, 2011 at 06:16:12PM +0200, gregor herrmann wrote: On Wed, 30 Mar 2011 11:56:22 +0100, Steve McIntyre wrote: Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. In the worst case that I'm looking at, I'm a little surprised by the names here on two fronts: libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz 1. Why the bundle ? Because the ftp-masters don't (or at least didn't) want small packages in the archive. From the packaging point of view we'd split them up immediately if that was ok for them. Cf. #606411. Ah, OK. :-( 2. Why such a silly long name? What will happen if somebody comes along with another perl module to add to this bundle, but with a name twice as long? Does the source name for this tarball have to contain the whole of the bundle name? As far as I understand source format v3 with multiple upstream tarballs, the first part (up to .orig) can't be changed as it needs to be the same as for the main package. [0] The second part (the component) name is free-form, and as I said earlier, here's a bit of room for us to shorten it (in this case e.g. from CGI-Application-Plugin-ValidateRM-2-3 to ValidateRM). OK. That would be nice... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- 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/20110331124539.gb18...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 30 Mar 2011, Steve McIntyre wrote: 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? Do you want it to actually work worth a damn (i.e. not croak on ext2-4, xfs and btrfs at the very least)? Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...). We really need to curb the long name insanity in the head. And might as well do it in a way that does not hinder our hability to get data where it is needed, i.e. keep it under 100 chars. I'm pushing for a little less than that, then the Joliet problems go away. We get an absolute maximum of 103 (Unicode) chars there, so I'm going to push for a max of 90 for normal uploads. That allows for small amounts of growth for security updates etc. There really is no excuse for such long deb names. If a naming convention requires it, fix the buggy naming convention. Agreed 100%. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back -- 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/20110331124823.gc18...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
On Thu, 31 Mar 2011, Steve McIntyre wrote: On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 30 Mar 2011, Steve McIntyre wrote: 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? Do you want it to actually work worth a damn (i.e. not croak on ext2-4, xfs and btrfs at the very least)? Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...). We really need to curb the long name insanity in the head. And might as well do it in a way that does not hinder our hability to get data where it is needed, i.e. keep it under 100 chars. I'm pushing for a little less than that, then the Joliet problems go away. We get an absolute maximum of 103 (Unicode) chars there, so I'm going to push for a max of 90 for normal uploads. That allows for small amounts of growth for security updates etc. Looks very sane. I like it! -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110331134406.gb19...@khazad-dum.debian.net
Re: MBF alert: packages with very long source / .deb filenames
Andreas Metzler ametz...@downhill.at.eu.org writes: In gmane.linux.debian.devel.general Joey Hess jo...@debian.org 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. Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. 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. Hello, An alternative approach would be to use a different *filename* while keeping the package name unchanged (This could be done on both mirrors and CD.) Iirc apt/dpkg have absolutely no problem with foo.deb containing version 1:3.2.1-11+squeeze2 of the openoffice.org-report-builder-bin i386 package. I do not know about dak, though. cu andreas Doesn't work for sources as the dsc files are signed and therefore unalterable. Unless you want to teach dpkg about the renaming rules too. MfG Goswin -- 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/87y63xxbl1.fsf@frosties.localnet
Re: MBF alert: packages with very long source / .deb filenames
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
Re: MBF alert: packages with very long source / .deb filenames
On Sat, Mar 26, 2011 at 03:18:12PM +0100, gregor herrmann wrote: On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote: 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. Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. In the worst case that I'm looking at, I'm a little surprised by the names here on two fronts: libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz 1. Why the bundle ? 2. Why such a silly long name? What will happen if somebody comes along with another perl module to add to this bundle, but with a name twice as long? Does the source name for this tarball have to contain the whole of the bundle name? -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. -- 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/20110330105622.gh7...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
On Wed, 30 Mar 2011, Steve McIntyre wrote: 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? Do you want it to actually work worth a damn (i.e. not croak on ext2-4, xfs and btrfs at the very least)? Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...). We really need to curb the long name insanity in the head. And might as well do it in a way that does not hinder our hability to get data where it is needed, i.e. keep it under 100 chars. There really is no excuse for such long deb names. If a naming convention requires it, fix the buggy naming convention. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110330125449.ga28...@khazad-dum.debian.net
Re: MBF alert: packages with very long source / .deb filenames
On Wed, 30 Mar 2011 11:56:22 +0100, Steve McIntyre wrote: Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. In the worst case that I'm looking at, I'm a little surprised by the names here on two fronts: libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz 1. Why the bundle ? Because the ftp-masters don't (or at least didn't) want small packages in the archive. From the packaging point of view we'd split them up immediately if that was ok for them. Cf. #606411. 2. Why such a silly long name? What will happen if somebody comes along with another perl module to add to this bundle, but with a name twice as long? Does the source name for this tarball have to contain the whole of the bundle name? As far as I understand source format v3 with multiple upstream tarballs, the first part (up to .orig) can't be changed as it needs to be the same as for the main package. [0] The second part (the component) name is free-form, and as I said earlier, here's a bit of room for us to shorten it (in this case e.g. from CGI-Application-Plugin-ValidateRM-2-3 to ValidateRM). Cheers, gregor [0] Although in this case the package name itself is made up and could be shortend from libcgi-application-basic-plugin-bundle-perl to something like libcgi-application-plugins-perl. -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: David Bowie: Tvc 15 signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
Joey Hess jo...@debian.org writes: 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. Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. 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. And how would users then get those files? If you have a kernel without udf filesystem support then apt/aptitude/... would suddenly fail to find some files. Same if udf isn't the default filesystem for cds. The files could be renamed and the new name be used in Packages/Sources files on the CD. But then the dsc files are broken. And they are signed so they can't be edited without loosing the signature. MfG Goswin -- 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/87fwq7is3k.fsf@frosties.localnet
Re: MBF alert: packages with very long source / .deb filenames
Hi, some technical facts about name lenght in Debian ISO 9660 images: Raphael Hertzog wrote: What happens if you try to put too-long filenames on the CD with Joliet enabled? libisofs, which produces the Debian i386 and amd64 images, truncates oversized Joliet names. Collisions get resolved by truncating them further and adding decimal counting numbers (aka mangling). Currently released libisofs is unable to write Joliet names longer than 64 characters. I have freshly implemented a relaxed limit of 103. Tests look good so far. The experimental code is uploaded as http://www.gnu.org/software/xorriso/xorriso-1.0.5.tar.gz Test reports from reading such an ISO image by a real Windows machine would be interesting ... :) E.g. with a file name of 100 characters: xorriso -as mkisofs -o test.iso -J -joliet-long -graft-points \ /0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789=/some/file/on/disk Steve McIntyre wrote: We already have arbitrary limits on filename length (~200 bytes or so on RockRidge), Rock Ridge specs allow unlimited name length. But libisofs allows only 255 currently. A name overflow of Rock Ridge is a FAILURE event which normally leads to an abort of the xorriso run. This abort is adjustable. In any case a file with overly long name will not get into the image. It seems unwise to exceed the X/Open minimum specification of 255 characters unless one knows that the reader can stand that. (http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html NAME_MAX = _XOPEN_NAME_MAX = 255 ) My own linux/limits.h says local NAME_MAX is 255. I will check this more thoroughly before the next release and might optionally allow longer Rock Ridge names. As for UDF (of which the specs are hard to read): ECMA-167, 14.4 File Identifier Descriptor, counts the file identifier length (L_FI) in a single byte field (Uint8). This limits name length to 255. It might be that the upper specification layer (e.g. UDF-2.60) provides means to represent longer names. One could make experiments with read-write mountable UDF on a machine that has NAME_MAX 255. Have a nice day :) Thomas -- 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/95980563027983@192.168.2.69
Re: MBF alert: packages with very long source / .deb filenames
Hi! Am 28.03.2011 11:23, schrieb Thomas Schmitt: Test reports from reading such an ISO image by a real Windows machine would be interesting ... :) E.g. with a file name of 100 characters: xorriso -as mkisofs -o test.iso -J -joliet-long -graft-points \ /0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789=/some/file/on/disk Didn't worked over here with an uptodate Windows XP. It is mountable, but only the filename is truncated to the first 64 characters. Best regards, Alexander -- 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/4d9054eb.8000...@debian.org
Re: MBF alert: packages with very long source / .deb filenames
Hi, Alexander Reichle-Schmehl wrote: xorriso -as mkisofs -o test.iso -J -joliet-long -graft-points \ /012345678901234567890123456789012345678901234567890123456789012345678901234 5678901234567890123456789=/some/file/on/disk Didn't worked over here with an uptodate Windows XP. It is mountable, but only the filename is truncated to the first 64 characters. Just to make sure that xorriso did it more or less right: Do you see longer names under /mnt on Linux after mount -o loop,norock test.iso /mnt (I do see all 100 characters.) Or do you get other results with the same command when replacing xorriso -as mkisofs by genisoimage ? Have a nice day :) Thomas -- 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/95980530632701@192.168.2.69
Re: MBF alert: packages with very long source / .deb filenames
Olaf van der Spek wrote: On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV jaq...@debian.org wrote: Olaf van der Spek wrote: That's not our problem, is it? It is, if we are trying to be as compatible as possible. Compatible with what? Bugs in other implementations? What does that really gain us? The ability for the discs to be read on as many systems as possible. I'm not going to pretend to know what all someone else may need to do with the data, but making it as readable as possible is certainly a laudable goal. A plausible scenario is someone having downloaded the images, burned them, and is now trying to read them prior to installation. If they are performing this on a Microsoft or Apple OS, and the filenames are corrupted, the implication is that the images are either corrupt or the burn was otherwise bad. How many times is a person going to attempt to fix the perceived problem before they give up? What is wrong with this so-called Universal Operating System? I can't even read the discs! -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- 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/20110328164343.gb29...@a.mx.sbih.org
Re: MBF alert: packages with very long source / .deb filenames
In gmane.linux.debian.devel.general Joey Hess jo...@debian.org 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. Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. 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. Hello, An alternative approach would be to use a different *filename* while keeping the package name unchanged (This could be done on both mirrors and CD.) Iirc apt/dpkg have absolutely no problem with foo.deb containing version 1:3.2.1-11+squeeze2 of the openoffice.org-report-builder-bin i386 package. I do not know about dak, though. cu andreas -- 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/2mr668-ua7@argenau.downhill.at.eu.org
Re: MBF alert: packages with very long source / .deb filenames
On Mon, 28 Mar 2011, John H. Robinson, IV wrote: Olaf van der Spek wrote: On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV jaq...@debian.org wrote: Olaf van der Spek wrote: That's not our problem, is it? It is, if we are trying to be as compatible as possible. Compatible with what? Bugs in other implementations? What does that really gain us? The ability for the discs to be read on as many systems as possible. I'm not going to pretend to know what all someone else may need to do with the data, but making it as readable as possible is certainly a laudable goal. A plausible scenario is someone having downloaded the images, burned them, and is now trying to read them prior to installation. If they are performing this on a Microsoft or Apple OS, and the filenames are corrupted, the implication is that the images are either corrupt or the burn was otherwise bad. Actually, note that we have a md5sum.txt on all CDs/DVDs. It would be quite handy if it could be verified on any OS. Best regards, Anne Bezemer -- 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/pine.lnx.4.64.1103281918150.5...@wormhole.robuust.nl
Re: MBF alert: packages with very long source / .deb filenames
On Mon, Mar 28, 2011 at 6:43 PM, John H. Robinson, IV jaq...@debian.org wrote: Compatible with what? Bugs in other implementations? What does that really gain us? The ability for the discs to be read on as many systems as possible. I'm not going to pretend to know what all someone else may need to do with the data, but making it as readable as possible is certainly a laudable goal. Sure, but is it more important than other goals like supporting long filenames? A plausible scenario is someone having downloaded the images, burned them, and is now trying to read them prior to installation. If they are performing this on a Microsoft or Apple OS, and the filenames are corrupted, the implication is that the images are either corrupt or the burn was otherwise bad. What Apple and MS OSs are affected? -- Olaf -- 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/AANLkTin-dxD5Nq3XKmuUs=2EJ=JzHMFFbhtxHkaep=j...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
Goswin von Brederlow wrote: And how would users then get those files? If you have a kernel without udf filesystem support then apt/aptitude/... would suddenly fail to find some files. Same if udf isn't the default filesystem for cds. That's what the Rock Ridge extensions are for. -- see shy jo signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
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. 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? If it means we have some unexpected filenames for long filenames on Windows, it's not a big deal IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110326075614.ga29...@rivendell.home.ouaza.com
Re: MBF alert: packages with very long source / .deb filenames
On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote: 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. Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Peter Jones: I Can Feel You signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
On Sat, 2011-03-26 at 15:18 +0100, gregor herrmann wrote: On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote: 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. Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. I don't think the longstanding naming policy for Perl binary packages has resulted in these very long names. (I believe I once had the longest-named binary package in the archive with libmaypole-plugin-authentication-usersessioncookie-perl, but that was still only 55 characters.) The really absurdly long names Steve found seem to be used for secondary source tarballs for some v3 source packages, where the file name essentially includes two full Perl module names. If that's specified in current Perl policy, it should be fixed (and can be fixed without confusing users). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: MBF alert: packages with very long source / .deb filenames
Am Freitag 25 März 2011, 21:59:31 schrieb Rene Engelhard: Hi, On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote: On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote: Hi, On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote: The longest is: libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.d eb at 71. Good, then any bug against openoffice.org is not needed, as that obviously will be + wontfix wheezy-ignore, because it simply can't be fixed as we need the transitional packages :) It still can have a version number much shorter than 1.0.3+LibO3.3.1-1. And there's no package out of openoffice.org which has that style of version. And no, it cannot have a shorter version in libreoffice (e.g. you simply can't remov the +LibO3.3.1-1 unless you get problems in versioning as the version before the + doesn't necessarily change between releases) At least the LibO can be dropped. HS -- 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/201103261453.10548.p...@hendrik-sattler.de
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV jaq...@debian.org wrote: That's not our problem, is it? It is, if we are trying to be as compatible as possible. Compatible with what? Bugs in other implementations? What does that really gain us? -- Olaf -- 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/AANLkTi=fhm8tko5mv9pcu9-r8ua23yw2hqsn2ckyq...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Sat, 26 Mar 2011 14:32:27 +, Ben Hutchings wrote: 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. Right, that's certainly true for the lib.*-perl packages, and I wouldn't know how we should rename them in a sane way. The really absurdly long names Steve found seem to be used for secondary source tarballs for some v3 source packages, where the file name essentially includes two full Perl module names. Thanks for the pointer, I admit that I have missed this detail. For the two packages listed in Steve's mail that gives us: libcgi-application-basic-plugin-bundle-perl_0.5-1.debian.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5-1.dsc libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Dispatch-2-17.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-AutoRunmode-0-17.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ConfigAuto-1-32.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-DBH-4-00.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-DebugScreen-0-06.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-DevPopup-1-06.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ErrorPage-1-21.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-FillInForm-1-15.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Forward-1-06.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-LogDispatch-1-02.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Redirect-1-00.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Session-1-03.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-Stream-2-10.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ViewCode-1-02.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Standard-Config-1-01.tar.gz libcgi-application-basic-plugin-bundle-perl_0.5.orig.tar.gz libcgi-application-plugin-authorization-perl_0.07-1.debian.tar.gz libcgi-application-plugin-authorization-perl_0.07-1.dsc libcgi-application-plugin-authorization-perl_0.07.orig-driver-activedirectory.tar.gz libcgi-application-plugin-authorization-perl_0.07.orig.tar.gz If that's specified in current Perl policy, it should be fixed (and can be fixed without confusing users). AFAIK the submodule names were just made up and can be shortened (in fact, for the second package it's already a made-up name). (Not that this gives us much room -- in the second case we're already down to 84 characters ...) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Brothers In Arms signature.asc Description: Digital signature
MBF alert: packages with very long source / .deb filenames
Hey folks, I've noticed a problem recently in the archive when building CDs, aggravated to a certain extent by the newer source formats. Some of the filenames in the archive are getting *very* long, and this is causing issues. As a matter of course, we build CDs with RockRidge and Joliet support so that we have long filenames for Linux and Windows users. The problem is that Joliet has a limit for filename length (64 characters), and technically we're already past that length. From genisoimage.1: -joliet-long Allow Joliet filenames to be up to 103 Unicode characters, instead of 64. This breaks the Joliet specification, but appears to work. Use with caution. I've been using -joliet-long as an option to the CD build scripts for a while without any noticeable issues, however we may be able to hit a brick wall. There are a few packages that are close to the (already over-spec) limit now, and if (for example) we end up with a security upload which adds a few characters to the filename then these files simply will not fit on our CDs any more. Therefore, I'm proposing a maximum limit of 80 characters on uploaded source / deb files to give us some headroom. With help from a friendly local ftpmaster, I've found the following packages that are currently over that limit (with a run through dd-list): Ying-Chun Liu (PaulLiu) paul...@debian.org libomxil-bellagio Nicholas Bamber nicho...@periapt.co.uk libcgi-application-plugin-authorization-perl (U) Debian Firebird Group pkg-firebird-gene...@lists.alioth.debian.org firebird2.5 Debian LibreOffice Maintainers debian-openoff...@lists.debian.org openoffice.org Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libcgi-application-plugin-authorization-perl Debian X Strike Force debia...@lists.debian.org compiz-fusion-plugins-unsupported Rene Engelhard r...@debian.org openoffice.org (U) Sean Finney sean...@debian.org compiz-fusion-plugins-unsupported (U) Damyan Ivanov d...@debian.org firebird2.5 (U) Jaldhar H. Vyas jald...@debian.org libcgi-application-basic-plugin-bundle-perl libcgi-application-plugin-authorization-perl (U) If we really want to meet the spec, we should be aiming for 64 characters, but that affects 98 packages and I'm not *too* bothered about it since testing shows no issues thus far. I'm tempted to file: * serious bugs on the packages over 90 characters * normal bugs on those over 80 * wishlist bugs on those over 64 Thoughts? -- Steve McIntyre, Cambridge, UK.st...@einval.com It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim. [ seen in ucam.chat ] signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote: Hey folks, I've noticed a problem recently in the archive when building CDs, aggravated to a certain extent by the newer source formats. Some of the filenames in the archive are getting *very* long, and this is causing issues. As a matter of course, we build CDs with RockRidge and Joliet support so that we have long filenames for Linux and Windows users. The problem is that Joliet has a limit for filename length (64 characters), and technically we're already past that length. From genisoimage.1: -joliet-long Allow Joliet filenames to be up to 103 Unicode characters, instead of 64. This breaks the Joliet specification, but appears to work. Use with caution. I've been using -joliet-long as an option to the CD build scripts for a while without any noticeable issues, however we may be able to hit a about brick wall. There are a few packages that are close to the (already -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
Hi, On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote: Debian LibreOffice Maintainers debian-openoff...@lists.debian.org openoffice.org Dead. Any anything there is just transitional packages you need tor squeeze-wheezy upgrades, so need to stay. Is libreoffice also affected? From your list it appears not... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- 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/20110325145032.ga...@rene-engelhard.de
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 03:50:32PM +0100, Rene Engelhard wrote: Hi, On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote: Debian LibreOffice Maintainers debian-openoff...@lists.debian.org openoffice.org Dead. Any anything there is just transitional packages you need tor squeeze-wheezy upgrades, so need to stay. Is libreoffice also affected? From your list it appears not... The longest is: libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb at 71. -- Steve McIntyre, Cambridge, UK.st...@einval.com C++ ate my sanity -- Jon Rabone -- 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/20110325152757.ga23...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre st...@einval.com wrote: users. The problem is that Joliet has a limit for filename length (64 characters), and technically we're already past that length. From genisoimage.1: 64 is quite low. Is there no way to use longer filenames that still works on all required platforms? Olaf -- 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/aanlktikn-bvcodvxp6hhhz-n9qr+we7edt7avsub1...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
Steve McIntyre wrote: I've noticed a problem recently in the archive when building CDs, aggravated to a certain extent by the newer source formats. Some of the filenames in the archive are getting *very* long, and this is causing issues. As a matter of course, we build CDs with RockRidge and Joliet support so that we have long filenames for Linux and Windows users. What is the use case for accessing long filenames from the CD in Windows? The files needed by win32-loader need to be accessible, and documentation too, but it should not matter if deb files cannot be looked up from within Windows. If these files could be dealt with, using Rock Ridge alone would be an alternative to consider: /README.html /README.mirrors.html /README.mirrors.txt /README.source /win32-loader.ini /css/debinstall-print.css /css/debinstall.css /doc/bug-log-access.txt /doc/bug-log-mailserver.txt /doc/bug-mailserver-refcard.txt /doc/bug-maint-info.txt /doc/bug-maint-mailcontrol.txt /doc/bug-reporting.txt /doc/constitution.txt /doc/debian-manifesto /doc/dedication /doc/mailing-lists.txt /doc/social-contract.txt /doc/source-unpack.txt /pics/blue-lowerleft.png /pics/blue-lowerright.png /pics/blue-upperleft.png /pics/blue-upperright.png /pics/debian-61.png /pics/logo-50.jpg /pics/openlogo-nd-50.png /pics/red-lowerleft.png /pics/red-lowerright.png /pics/red-upperleft.png /pics/red-upperright.png /doc/FAQ/debian-faq.en.html.tar.gz /doc/FAQ/debian-faq.en.pdf.gz /doc/FAQ/debian-faq.en.ps.gz /doc/FAQ/debian-faq.en.txt.gz Is it possible to provide Joliet filenames for only a subset of files? -- see shy jo signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
Hi, On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote: The longest is: libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb at 71. Good, then any bug against openoffice.org is not needed, as that obviously will be + wontfix wheezy-ignore, because it simply can't be fixed as we need the transitional packages :) Grüße/Regards, René -- 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/20110325160954.gb...@rene-engelhard.de
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre st...@einval.com wrote: 64 is quite low. Is there no way to use longer filenames that still works on all required platforms? To do that, we'll have to switch to a different filesystem. That's a possibility (maybe UDF), but there's probably even more of a chance of compatibility problems then. Why's that? Isn't UDF widely supported? -- Olaf -- 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/aanlktikog-er7p3d2azypdf4vwbffgep78i+t9m2r...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 11:52:35AM -0400, Joey Hess wrote: Steve McIntyre wrote: I've noticed a problem recently in the archive when building CDs, aggravated to a certain extent by the newer source formats. Some of the filenames in the archive are getting *very* long, and this is causing issues. As a matter of course, we build CDs with RockRidge and Joliet support so that we have long filenames for Linux and Windows users. What is the use case for accessing long filenames from the CD in Windows? The files needed by win32-loader need to be accessible, and documentation too, but it should not matter if deb files cannot be looked up from within Windows. There are uses I've heard about, including (apparently quite common) using CDs and DVDs to seed a mirror on a Windows server. Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- 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/20110325160115.gb23...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 04:48:12PM +0100, Olaf van der Spek wrote: On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre st...@einval.com wrote: users. The problem is that Joliet has a limit for filename length (64 characters), and technically we're already past that length. From genisoimage.1: 64 is quite low. Is there no way to use longer filenames that still works on all required platforms? To do that, we'll have to switch to a different filesystem. That's a possibility (maybe UDF), but there's probably even more of a chance of compatibility problems then. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back -- 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/20110325160823.gc23...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
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. Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. 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. -- see shy jo signature.asc Description: Digital signature
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 05:13:03PM +0100, Olaf van der Spek wrote: On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre st...@einval.com wrote: 64 is quite low. Is there no way to use longer filenames that still works on all required platforms? To do that, we'll have to switch to a different filesystem. That's a possibility (maybe UDF), but there's probably even more of a chance of compatibility problems then. Why's that? Isn't UDF widely supported? Implementations often widely differ in their limitations - see the Wikipedia page for more details. The suggested way to make a safe UDF DVD is often along the lines of use the ISO9660 bridge format. :-( -- 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/20110325162753.ge23...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre st...@einval.com wrote: Why's that? Isn't UDF widely supported? Implementations often widely differ in their limitations - see the Wikipedia page for more details. The suggested way to make a safe UDF DVD is often along the lines of use the ISO9660 bridge format. :-( That's not our problem, is it? -- Olaf -- 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/AANLkTi=vxP9uJ8PdnuMQ3HKK=R5d05S+RD-jcfcNO5=q...@mail.gmail.com
Re: MBF alert: packages with very long source / .deb filenames
On 2011-03-25, Joey Hess jo...@debian.org wrote: Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. 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. And on that Windows you get your own share of fun on an OS that's case-insensitive, I guess. Kind regards Philipp Kern -- 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/slrniopi0n.1j7.tr...@kelgar.0x539.de
Re: MBF alert: packages with very long source / .deb filenames
Olaf van der Spek wrote: On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre st...@einval.com wrote: Why's that? Isn't UDF widely supported? Implementations often widely differ in their limitations - see the Wikipedia page for more details. The suggested way to make a safe UDF DVD is often along the lines of use the ISO9660 bridge format. :-( That's not our problem, is it? It is, if we are trying to be as compatible as possible. What about keeping the first cd/dvd/bd as compatible as possible, and not worrying about the subsequent ones? As mentioned, and mirror seeding would have to be synced anyway. -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- 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/20110325165515.ga30...@a.mx.sbih.org
Re: MBF alert: packages with very long source / .deb filenames
On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote: Hi, On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote: The longest is: libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb at 71. Good, then any bug against openoffice.org is not needed, as that obviously will be + wontfix wheezy-ignore, because it simply can't be fixed as we need the transitional packages :) It still can have a version number much shorter than 1.0.3+LibO3.3.1-1. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110325204815.ga32...@angband.pl
Re: MBF alert: packages with very long source / .deb filenames
Hi, On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote: On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote: Hi, On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote: The longest is: libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb at 71. Good, then any bug against openoffice.org is not needed, as that obviously will be + wontfix wheezy-ignore, because it simply can't be fixed as we need the transitional packages :) It still can have a version number much shorter than 1.0.3+LibO3.3.1-1. And there's no package out of openoffice.org which has that style of version. And no, it cannot have a shorter version in libreoffice (e.g. you simply can't remov the +LibO3.3.1-1 unless you get problems in versioning as the version before the + doesn't necessarily change between releases) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- 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/20110325205931.gd...@rene-engelhard.de
Re: MBF alert: packages with very long source / .deb filenames
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? Is it possible to provide Joliet filenames for only a subset of files? It is, yes. But not something I'd like to do if we can avoid it. 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. -- Steve McIntyre, Cambridge, UK.st...@einval.com I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop -- Vivek Dasmohapatra -- 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/20110325220948.gd13...@einval.com
Re: MBF alert: packages with very long source / .deb filenames
John H. Robinson, IV wrote: Olaf van der Spek wrote: On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre st...@einval.com wrote: Why's that? Isn't UDF widely supported? Implementations often widely differ in their limitations - see the Wikipedia page for more details. The suggested way to make a safe UDF DVD is often along the lines of use the ISO9660 bridge format. :-( That's not our problem, is it? It is, if we are trying to be as compatible as possible. Absolutely, yes. What about keeping the first cd/dvd/bd as compatible as possible, and not worrying about the subsequent ones? As mentioned, and mirror seeding would have to be synced anyway. Ewww, special casing...! -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss -- 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/e1q3f7p-0008oe...@jack.mossbank.org.uk
