Re: [PATCH] Prefer https: for GNU and FSF URLs

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 21 Sep 2017, Paul Eggert wrote:

> The first attachment is a standin for a purely mechanical replacement
> (explained in the attachment), which is over 5 MB and so a bit long for this
> email. The second attachment is a patch that merely updates some files from
> upstream sources that have already switched to https:.

This command looks like it would modify some generated files, rather than 
modifying their sources and regenerating.

See the cases in scripts/update-copyrights that avoid modifying generated 
files: INSTALL intl/plural.c locale/C-translit.h 
locale/programs/charmap-kw.h locale/programs/locfile-kw.h po/libc.pot 
sysdeps/gnu/errlist.c, and configure and preconfigure scripts in some 
cases (where corresponding .ac files exist).  (Not all of those actually 
contain http: URLs.)

In such cases, if the http: URL comes from the corresponding sources in 
glibc, it's appropriate to modify the sources and then regenerate the 
generated file (which might or might not produce the same results as 
modifying both sources and generated file directly, depending on whether 
the generator does e.g. line wrapping).  But if it comes from text copied 
in by another tool (autoconf / bison), you need to have an updated release 
of that tool that uses https: and regenerate with that updated release.  
What should be avoided in all cases is modifications (to either source or 
generated files) that mean generated files no longer correspond to their 
sources.

(For bison and gperf it might also be reasonable to propose making them 
required tools for building glibc, stopping checking in those generated 
files and arranging for the build system to generate them in the build 
directory rather than the source directory.)

With the same caveats about which files are appropriate to modify, 
http://(sourceware.org|sources.redhat.com) URLs are also appropriate to 
change to https://sourceware.org URLs.

It may make sense to exclude both the generated files and their sources 
from the mechanical change, so they can be dealt with individually 
afterwards.

-- 
Joseph S. Myers
joseph@codesourcery.com