Hello. Chipping in my 2 cents here: I would suggest stricter rules for the ports rather than a hacking the tools.
We are talking about the OpenBSD ports, right? So if it is the ports, the name of the file should not matter that much, as long as the build process can find it. In other words: Since the build process has control over the filenames, it is also possible to change them, and apply a patch to the Makefile (or whichever), so that it can find it. So, in my opinion, a too long filename in a port can be seen as breaking said port, something which can be checked before the tar is being generated. And in that case, an alert could be send out the maintainers. (That is what perl is for...) The maintainer could then shorten the filename, patch, and reupload. That would be an intermediate (and safer) solution, until somebody starts working on tar 2.0. Thomas > Stuart Henderson <s...@spacehopper.org> hat am 03.05.2022 16:45 geschrieben: > > > On 2022/05/03 15:13, Solène Rapenne wrote: > > Le Tue, 3 May 2022 14:10:19 +0100, > > Stuart Henderson <s...@spacehopper.org> a écrit : > > > > > On 2022/05/02 20:35, Jonathan Thornburg wrote: > > > > The 7.1 ports.tar.gz (I tried downloading from both > > > > https://ftp.openbsd.org/pub/OpenBSD/ > > > > https://openbsd.cs.toronto.edu/pub/OpenBSD/ > > > > and verified that they gave identical files; checksums are below) > > > > appears to have a slightly corrupted 'graphics/libraw' port: > > > > > > > > % /bin/tar xzf /tmp/ports.tar.gz > > > > % cd ports > > > > % ls -d g* > > > > games/ geo/ gnome/ graphics/ grapics/ > > > > > > > > I was curious about the directory name 'grapics' (which looks like a > > > > 1-letter typo from 'graphics'), so I looked around. 'grapics' contains > > > > only a single port, libraw, and that port is missing various files: > > > > > > These directories are present in the cvs tree due to broken imports in the > > > past (there are a bunch of others). This one was from 2010. I think that > > > when the tar was created it was done from a checkout without -d. > > > > > > It also misses some files with names which are too long for the default > > > tar format. > > > > > > I recommend ignoring this file and doing a checkout from anoncvs. > > > > > > > Should we continue to distribute that file is it's broken due to tar > > limitations? > > Another option would be to distribute a file that works ok with OpenBSD > (and FreeBSD, but not GNU) tar: > > cd /usr/ports > cvs up -Pd -r OPENBSD_X_Y_BASE > cd .. > pax -x cpio -w ports | gzip -9 > ports.tar.gz > > A better option would be to add support for writing extended headers > in tar(1), it already handles reading them (so, if the tree was archived > with bsdtar/gtar which do this it would include all the files and tar(1) > could unpack them OK, but using a non-OpenBSD archiver to produce a > file distributed by OpenBSD would be quite distasteful). > > anoncvs is usually not all that slow though.
