How about the attached patch ?
On Tue, Jul 07, 2015 at 09:58:14PM +0000, Karl Berry wrote:
I'm seeing an increasing number of programs, whose configure and/or
makefile have been written, to open a connection to some remote url
(usually controlled by the project) download file(s) from there and
build them into the software.
I've also seen this routinely done by bootstrap scripts in GNU packages,
e.g., the one that's part of gnulib and used by many packages, but not
in releases.
I think this is a bad idea
I fully agree. I personally wish that even bootstrap scripts wouldn't
do it, but I think forbidding that would be going too far.
I think we should put a statement about it in the GCS.
Sounds fine to me, FWIW. You could draft some (concise) text ...
On a somewhat related front, the GCS could also mention that merely
putting a tag into a repository is not sufficient for what we call
"making a release".
karl-- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
? GCS.patch
Index: standards.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/standards.texi,v
retrieving revision 1.242
diff -U 3 -r1.242 standards.texi
--- standards.texi 23 Apr 2015 15:48:55 -0000 1.242
+++ standards.texi 8 Jul 2015 01:01:56 -0000
@@ -3,7 +3,7 @@
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate April 23, 2015
+@set lastupdate July 8, 2015
@c %**end of header
@dircategory GNU organization
@@ -4082,6 +4082,11 @@
major version and a minor. We have no objection to using more than
two numbers, but it is very unlikely that you really need them.
+Making a release means providing a package for distribution. If you
+use a version control system, you might also want to tag the point in
+the history where the release was made. But this in itself is not
+sufficient.
+
Package the distribution of @code{Foo version 69.96} up in a gzipped tar
file with the name @file{foo-69.96.tar.gz}. It should unpack into a
subdirectory named @file{foo-69.96}.
@@ -4128,6 +4133,11 @@
install whichever versions of whichever packages they like. Do not
induce new dependencies on other software lightly.
+Don't allow any part of the build or configure process to open a
+network connection in order to download files remotely (or for any other reason).
+The distribution should successfully build on a machine disconnected
+from the internet.
+
Non-source files that might actually be modified by building and
installing the program should @strong{never} be included in the
distribution. So if you do distribute non-source files, always make
signature.asc
Description: Digital signature
