On 2022/05/04 08:58, Thomas Dettbarn wrote: > 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.
To be clear, the problem is in pathnames of some patch files, which are generated by "make update-patches" and stored in the ports tree, and the problem only occurs when a tar of the ports tree is produced with /bin/tar, something which is done for releases by someone who isn't working on ports, and the produced file is typically not used by ports developers (we work on -current not a frozen snapshot of old source, so we update from the repository often). It doesn't affect anything in packages, which are produced by Perl ustar which does use extended headers for long path names. > 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. It's not that big a problem in ports. Only a couple of ports are likely to have pathnames this long and people fetching this tar are unlikely to build them. Adding a hack to the ports tools to avoid tickling a deficiency in a base OS tool doesn't seem the right way. To be honest the bigger problem is if people use tar for their own backups unaware of the restriction (which after all is not a problem with the standard tar on most other OS they might be using). Someone might be using tar themselves to backup a ports tree in a different location (say, home/user/ports/XX rather than ports/XX) and they'll hit the problem with a shorter patch filename so some auto check win't pick that up. More importantly they might be backing up a personal file rather than some patchfile in a widely mirrored repo and make the mistake of failing to review stderr messages.
