#956 Remove mentions of EOL Fedoras
Opened 8 months ago by churchyard. Modified 3 months ago
churchyard/packaging-committee remove_eol  into  master

file modified
-3
@@ -73,9 +73,6 @@ 

  $ make serve

  ```

  

- Note that running `make` may require root

- on releases earlier than Fedora 29.

- 

  ### Writing

  

  [Antora](https://antora.org/) is used for

@@ -32,7 +32,7 @@ 

  * the various MPI environments where users care both about which MPI environment they compile against and which one they run against

  * choice of editor when the user invokes "vi" where the user will care about feature availability, compatibility with plugins, etc

  

- Cases where parallel installation is desirable but alternatives is unsuitable may be scenarios where link:../EnvironmentModules/[Environment Modules] are appropriate. MPI and python-sphinx (from Fedora 26 on) are example packages using environment-modules for this purpose.

+ Cases where parallel installation is desirable but alternatives is unsuitable may be scenarios where link:../EnvironmentModules/[Environment Modules] are appropriate. MPI and python-sphinx (until Fedora 31) are example packages using environment-modules for this purpose.

  

  == How to use alternatives

  

@@ -16,7 +16,7 @@ 

  

  == Creating environment modules

  

- To install an environment module, place a module file into `+%{_modulesdir}+`, which should evaluate to `+/usr/share/modulefiles+`. This macro is available in Fedora 21+ and EPEL 7+. The directory `+/usr/share/Modules/modulefiles+` is to be used only for internal modules of environment-modules. `+/etc/modulefiles+` is available to local system administrator use.

+ To install an environment module, place a module file into `+%{_modulesdir}+`, which should evaluate to `+/usr/share/modulefiles+`. This macro is available in Fedora and EPEL 7+. The directory `+/usr/share/Modules/modulefiles+` is to be used only for internal modules of environment-modules. `+/etc/modulefiles+` is available to local system administrator use.

  

  The module files are plain text with optional tcl syntax, for instance an environment module for 64-bit OpenMPI `+mpi/openmpi-x86_64+`:

  

@@ -64,4 +64,4 @@ 

  

  == Testing

  

- Some add-ons have not yet updated their test suites for GAP 4.8. If a GAP add-on's test suite invokes `+ReadTest(foo)+`, modify it to invoke `+Test(foo, rec( compareFunction := "uptowhitespace" ) )+` instead for Fedora 24 and later.

+ Some add-ons have not yet updated their test suites for GAP 4.8. If a GAP add-on's test suite invokes `+ReadTest(foo)+`, modify it to invoke `+Test(foo, rec( compareFunction := "uptowhitespace" ) )+` instead.

@@ -185,7 +185,7 @@ 

  

  == C extensions and PECL packages configuration file

  

- Each extension should drop a configuration file in %\{php_inidir} and/or %\{php_ztsinidir} to enable the extension. This file must contains the name of the loaded extension. Starting with Fedora 21, the file must use a numeric prefix to ensure correct load order:

+ Each extension should drop a configuration file in %\{php_inidir} and/or %\{php_ztsinidir} to enable the extension. This file must contains the name of the loaded extension. The file must use a numeric prefix to ensure correct load order:

  

  * range 00-19 is reserved for zend_extensions (ex: 10-opcache.ini, 15-xdebug.ini...)

  * range 20-39 is reserved for extensions from php sources (ex: 20-pdo.ini, 30-pdo_pgsql.ini...)
@@ -316,7 +316,7 @@ 

  %{!?php_extdir: %{expand: %%global php_extdir %(php-config --extension-dir)}}

  ....

  

- In Fedora 24 and later, module (un)registration is handled automatically by file triggers in the php-pear package.

+ Module (un)registration is handled automatically by file triggers in the php-pear package.

  

  For older releases, here are some recommended scriptlets for properly registering and unregistering a module:

  

@@ -152,7 +152,7 @@ 

  

  === Linker Configuration Files

  

- Packages which place linker configuration files in `+/etc/ld.so.conf.d+` MUST call ldconfig in `+%post+` and `+%postun+` (on all Fedora releases) even if they install no actual libraries. They MUST NOT use the `+%ldconfig+`, `+%ldconfig_post+`, `+%ldconfig_postun+` or `+%ldconfig_scriptlets+` macros to do this, since these macros do not have any effect on Fedora 28 and newer. Instead simply call `+/sbin/ldconfig+` directly in both `+%post+` and `+%postun+` as well as adding the necessary dependencies when necessary:

+ Packages which place linker configuration files in `+/etc/ld.so.conf.d+` MUST call ldconfig in `+%post+` and `+%postun+` (on all Fedora releases) even if they install no actual libraries. They MUST NOT use the `+%ldconfig+`, `+%ldconfig_post+`, `+%ldconfig_postun+` or `+%ldconfig_scriptlets+` macros to do this, since these macros do not have any effect on Fedora. Instead simply call `+/sbin/ldconfig+` directly in both `+%post+` and `+%postun+` as well as adding the necessary dependencies when necessary:

  

  ....

  %post -p /sbin/ldconfig
@@ -175,7 +175,7 @@ 

  [...]

  ....

  

- In addition, in Fedora 28 or newer the following applies: If the configuration file added to `+/etc/ld.so.conf.d+` specifies a directory into which other other packages may install files, and that directory is not located in the directory hierarchy beneath one of `+/lib+`, `+/usr/lib+`, `+/lib64+` or `+/usr/lib64+`, then the package adding the configuration file MUST also include the following file triggers which cause ldconfig to be run automatically when necessary:

+ If the configuration file added to `+/etc/ld.so.conf.d+` specifies a directory into which other other packages may install files, and that directory is not located in the directory hierarchy beneath one of `+/lib+`, `+/usr/lib+`, `+/lib64+` or `+/usr/lib64+`, then the package adding the configuration file MUST also include the following file triggers which cause ldconfig to be run automatically when necessary:

  

  ....

  %transfiletriggerin -P 2000000 -- DIRECTORIES

@@ -1745,7 +1745,7 @@ 

  * Files which are not installed as executables SHOULD NOT have shebang lines.

  * Language-specific guidelines may have additional restrictions.

  

- In Fedora 28 and later, shebang lines for executable scripts are automatically modified to convert calls to `+env+` into direct use of the proper executable in `+/usr/bin+`. Various checks are also applied to verify that the shebang lines are valid, and the build process can fail as a result of these. Finally, other language-specific modifications may also be made. It is thus generally unnecessary, in Fedora 28 or later, to manually modify executable scripts to fix `+env+` usage as long as this functionality is enabled.

+ Shebang lines for executable scripts are automatically modified to convert calls to `+env+` into direct use of the proper executable in `+/usr/bin+`. Various checks are also applied to verify that the shebang lines are valid, and the build process can fail as a result of these. Finally, other language-specific modifications may also be made. It is thus generally unnecessary, to manually modify executable scripts to fix `+env+` usage as long as this functionality is enabled.

  

  If the automatic checks and modifications break a package, there are two primary options:

  
@@ -1758,7 +1758,7 @@ 

  

  BRP scripts are injected at the end of `+%install+` (via the `+%__os_install_post+` macro) and perform some automatic sanity checks of, or adjustments to, files installed in the build root.

  

- All packages SHOULD always be subject to all the BRP scripts, but sometimes it is necessary for a package to opt-out of certain ones. From Fedora 28, it is possible to disable any BRP script simply by defining the corresponding variable to `+%{nil}+`. For example, to disable the brp-python-bytecompile script:

+ All packages SHOULD always be subject to all the BRP scripts, but sometimes it is necessary for a package to opt-out of certain ones. It is possible to disable any BRP script simply by defining the corresponding variable to `+%{nil}+`. For example, to disable the brp-python-bytecompile script:

  

  ....

  # Turn off Python bytecode compilation because this is a Jython

no initial comment

I would just drop everything up to and including the colon. Without the version qualifier there's nothing this is "in addition" to, the guideline that follows carries the same weight as any other. It shouldn't be introduced as if it's an afterthought, a tacked-on restriction, or only contextually applicable.

rebased onto 44b5dae

3 months ago