bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* maint.mk suggestion for gnupload
@ 2021-05-08 11:34 Eric Blake
  2021-05-08 11:49 ` Simon Josefsson via Gnulib discussion list
  2021-05-10 19:11 ` Eric Blake
  0 siblings, 2 replies; 3+ messages in thread
From: Eric Blake @ 2021-05-08 11:34 UTC (permalink / raw)
  To: Gnulib bugs; +Cc: m4-discuss

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?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: maint.mk suggestion for gnupload
  2021-05-08 11:34 maint.mk suggestion for gnupload Eric Blake
@ 2021-05-08 11:49 ` Simon Josefsson via Gnulib discussion list
  2021-05-10 19:11 ` Eric Blake
  1 sibling, 0 replies; 3+ messages in thread
From: Simon Josefsson via Gnulib discussion list @ 2021-05-08 11:49 UTC (permalink / raw)
  To: Eric Blake; +Cc: Gnulib bugs, m4-discuss

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

Eric Blake <eblake@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: maint.mk suggestion for gnupload
  2021-05-08 11:34 maint.mk suggestion for gnupload Eric Blake
  2021-05-08 11:49 ` Simon Josefsson via Gnulib discussion list
@ 2021-05-10 19:11 ` Eric Blake
  1 sibling, 0 replies; 3+ messages in thread
From: Eric Blake @ 2021-05-10 19:11 UTC (permalink / raw)
  To: Gnulib bugs, Simon Josefsson; +Cc: m4-discuss

On 5/8/21 6:34 AM, Eric Blake wrote:

> 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?

Aha - I just discovered you can do this in cfg.mk:

# Update m4-latest.tar.* symlinks during 'make stable/beta'.
GNUPLOADFLAGS = --symlink-regex

without having to tweak maint.mk.  Thus, it is already opt-in, as Simon
suggested.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-05-10 19:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-08 11:34 maint.mk suggestion for gnupload Eric Blake
2021-05-08 11:49 ` Simon Josefsson via Gnulib discussion list
2021-05-10 19:11 ` Eric Blake

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).