Eric Blake <ebl...@redhat.com> writes: > It was pointed out to me that for multiple years, m4's > 'm4-latest.tar.XX' links were out of date at https://ftp.gnu.org/gnu/m4/ > - the links were created in in 2013 when I released m4-1.4.17, but never > updated in 2016 when I released m4-1.4.18. > > I managed to fix the latest links today with: > > $ build-aux/gnupload --to ftp.gnu.org:m4 \ > --symlink m4-1.4.18.tar.gz m4-latest.tar.gz \ > --symlink m4-1.4.18.tar.gz.sig m4-latest.tar.gz.sig \ > --symlink m4-1.4.18.tar.bz2 m4-latest.tar.bz2 \ > --symlink m4-1.4.18.tar.bz2.sig m4-latest.tar.bz2.sig \ > --symlink m4-1.4.18.tar.xz m4-latest.tar.xz \ > --symlink m4-1.4.18.tar.xz.sig m4-latest.tar.xz.sig > > but it would be a lot nicer if I didn't have to remember to do that > after the fact. In fact, reading gnupload --help says it is as simple > as calling: > > $ gnupload --to ... --symlink-regex ... > > in the first place. But --symlink-regex is not listed in the suggested > output of 'make beta' or 'make stable' from maint.mk, which is why I > missed that simpler step back in 2016, and nearly missed it again today > when I did the m4-1.4.18b beta release. Is it worth patching maint.mk > to add --symlink-regex in the suggested gnupload instructions it generates?
Yes, please. I'm sure I would make the same mistake if an old *-latest.* symlink existed for some project. I think the symlinks are problematic because the version number isn't recorded in the tarball filename if anyone downloads the m4-latest.tar.gz files. So I wouldn't recommended new projects to create them. Can the patch be done in a way that we don't cause all projects to create these symlinks? Perhaps a compromise would be to extend maint.mk to make it possibly to opt-in for *-latest.* support in cfg.mk, but cause the default behaviour to be off by default. If people agree with me that *-latest.* symlinks are a bad idea, that is, which I'm not certain off. /Simon
signature.asc
Description: PGP signature
