PR#1115: Fix more bad links (insecure or broken) - packaging-committee

packaging-committee

#1115 Fix more bad links (insecure or broken)

Merged 2 years ago by tibbs. Opened 2 years ago by mcinglis.

mcinglis/packaging-committee fix-links into master

Use HTTPS SemBr link in README

Malcolm Inglis • 2 years ago

fc86c8a

Use HTTPS and correct links in Tcl guidelines

Malcolm Inglis • 2 years ago

692e30a

Use HTTPS and correct links in Modules guidelines

Malcolm Inglis • 2 years ago

d45d970

Use HTTPS and correct links in OCaml guidelines

Malcolm Inglis • 2 years ago

cfcf1ca

README.md

file modified

+1 -1

		`@@ -91,6 +91,6 @@`
		`The Packaging Committee tries to follow the following,`
		`and it is preferred that pull requests do the same.`

		`- * Use [Semantic Line Breaks](http://sembr.org/) to make diffing simpler.`
		`+ * Use [Semantic Line Breaks](https://sembr.org/) to make diffing simpler.`
		* Prefer `https://example.com[here]` over `link:https://example.com[here]`
		* Prefer `[#some-ref]` over `[[some-ref]]`

guidelines/modules/ROOT/examples/ocaml-example.spec

file modified

+2 -2

		`@@ -7,8 +7,8 @@`
		`Summary: OCaml library for fooing bars`

		`License: LGPL+`
		`- URL: http://www.example.com/foolib`
		`- Source0: http://www.example.com/foolib-1.2.3.tar.gz`
		`+ URL: https://www.example.com/foolib`
		`+ Source0: https://www.example.com/foolib-1.2.3.tar.gz`
		`BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)`

		`BuildRequires: ocaml, ocaml-findlib-devel`

guidelines/modules/ROOT/pages/EnvironmentModules.adoc

file modified

+2 -2

		`@@ -12,7 +12,7 @@`
		To load a module run e.g. `+$ module load mpi/openmpi-x86_64+`.
		To unload a module, run e.g. `+$module unload mpi/openmpi-x86_64+`.

		- The upstream documentation for the module command is available http://modules.sourceforge.net/man/module1.html[here] or with `+man module+`.
		+ The upstream documentation for the module command is available https://modules.readthedocs.io/en/stable/module.html[here] or with `+man module+`.

		`== Creating environment modules`

		`@@ -48,7 +48,7 @@`

		It is also possible to set `+CFLAGS+` and `+LDFLAGS+` with the above manner, but in the case of MPI compilers it is not necessary since the compilers are invoked with the `+mpicc+`, `+mpicxx+`, `+mpif77+` and `+mpif90+` wrappers that already contain the necessary include and library paths. Also, in the case of development packages an override of `+CFLAGS+` and/or `+LDFLAGS+` is not sane, as it may cause trouble in building RPMs as it overrides `+%{optflags}+`.

		- The upstream documentation for module files is available http://modules.sourceforge.net/man/modulefile4.html[here] or with `+man modulefile+`.
		+ The upstream documentation for module files is available https://modules.readthedocs.io/en/stable/modulefile.html[here] or with `+man modulefile+`.

		`== Switching between module implementations`

guidelines/modules/ROOT/pages/OCaml.adoc

file modified

+1 -1

		`@@ -39,7 +39,7 @@`

		`If the package contains *.so files, then they should have rpaths removed, as per Fedora packaging guidelines.`

		`- The packager should check the META file footnote:[http://www.ocaml-programming.de/packages/documentation/findlib/guide-html/x131.html[Findlib users guide - writing META files.]]. If there is no META file, then the packager should create one, include it in the package, and pass it to the upstream maintainer.`
		`+ The packager should check the META file footnote:[http://projects.camlcity.org/projects/dl/findlib-1.9.1/doc/ref-html/r759.html[findlib Reference Manual - META files.]]. If there is no META file, then the packager should create one, include it in the package, and pass it to the upstream maintainer.`

		`Rationale: OCaml does not support dynamic linking of binaries, and even if it did with the current module hash system for expressing strict typing requirements almost any conceivable change to a library would require the binary to be recompiled. OCaml scripts are the closest we come to dynamic linking, in as much as they do not usually depend on a specific version of a library (albeit this only works because the scripts are recompiled each time they run).`

guidelines/modules/ROOT/pages/Tcl.adoc

file modified

+1 -1

		`@@ -126,4 +126,4 @@`
		If the extension does not provide a `+fooConfig.sh+` file, then the shared library must not be installed directly in `+%{_libdir}+`, but in the package-specific installation directory in `+%{tcl_sitearch}+` instead. This may require a patch to update the extension's `+pkgIndex.tcl+` file to look for the shared library in the correct location.

		`Stubs are ok if put in -devel subpackage:`
		- Some Tcl extensions provide a static 'stub' library. Stub libraries are a Tcl-ism to provide version-independent dynamic linking on a variety of platforms. These are not normal static libraries that provide the library's actual functionality, but instead provide a level of indirection pointing to the shared library. These stub libraries do not have the same static linking issues that are generally frowned upon in Fedora, and thus are acceptable. If a package provides such a stub library, it must be placed in a -devel subpackage. More information on stubs can be found on the Tcl wiki: http://wiki.tcl.tk/285
		+ Some Tcl extensions provide a static 'stub' library. Stub libraries are a Tcl-ism to provide version-independent dynamic linking on a variety of platforms. These are not normal static libraries that provide the library's actual functionality, but instead provide a level of indirection pointing to the shared library. These stub libraries do not have the same static linking issues that are generally frowned upon in Fedora, and thus are acceptable. If a package provides such a stub library, it must be placed in a -devel subpackage. More information on stubs can be found on the Tcl wiki: https://wiki.tcl-lang.org/page/Stubs

mcinglis commented 2 years ago

I noticed the latest master had recent changes from Jason Tibbs in fixing HTTP or broken links across the guidelines.

Wanting to help, I ran a grep -R http:// and found some more that were insecure, or just broken. This PR fixes and updates those that could be. There are still a few http:// hold-outs with links, but none left that I could see with a satisfactory replacement.

Note that this PR is complementary to Jason's currently-pending PR #1109 "Fix some bad links"; there are no conflicts.

Apologies if anything is off with this PR; this is my first PR to the Fedora Project. Welcoming any and all suggestions for improvement :-)

decathorpe commented 2 years ago

Looks good to me. Some are plain http -> https changes where applicable, and the other two fix two broken (or already redirecting) links to their new location. :thumbsup: from me