Add RHEL/Rocky Linux 10 support and drop RHEL/CentOS 7 and Debian 10 support #71
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit git-lfs/git-lfs@23fbfe8 of PR git-lfs/git-lfs#5911, since all the distribution versions based on Red Hat Enterprise Linux (RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for these platforms or build packages for them. Because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we now remove the Dockerfile we used to build packages for the RHEL/CentOS 7 and SLES 12 platforms.
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit git-lfs/git-lfs@23fbfe8 of PR git-lfs/git-lfs#5911, since all the distribution versions based on Debian 10 ("buster") for which we previously built Debian packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for this platform or build packages for it. Because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we now remove the Dockerfile we used to build packages for the Debian 10 platform.
Rocky Linux 10.0 was recently released, following the release last month of RHEL (Red Hat Enterprise Linux) 10.0, and because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we now add a Dockerfile we can use to build packages for the RHEL/Rocky Linux 10 platform. Note that except for the name of the base image in the FROM statement, this new Dockerfile is identical to the one for the RHEL/Rocky Linux 9 platform.
In a previous commit in this PR we removed the Dockerfile we used to build RPM packages for the Red Hat Enterprise Linux (RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 platforms. As well, in 2019 we removed the Dockerfile we used to build Debian packages for the Debian 7 platform in commit 5e7bf33 of PR git-lfs#26. Several of our shell scripts still reference these platforms in their comments, however, so we update those scripts now to provide more up-to-date usage examples.
larsxschneider
approved these changes
Jun 18, 2025
chrisd8088
added a commit
to chrisd8088/build-dockers
that referenced
this pull request
Jun 18, 2025
In PR git-lfs/git-lfs#5054 we updated the source files of the manual pages for the Git LFS client from the Ronn format to the AsciiDoc format, which necessitated changing our Linux package build processes to use the Asciidoctor Ruby gem to generate manual pages in Roff and HTML formats. At the time, an RPM package for a 2.0.x version of the Asciidoctor Ruby gem was not easily available for all the platforms based on Red Hat Enterprise Linux (RHEL) that we supported, particularly RHEL/CentOS 7, so in commit git-lfs/git-lfs@db9a821 of PR git-lfs/git-lfs#5054 we updated the "rpm/build_rpms.bsh" script in our main project's repository to build and install a custom RPM package with Asciidoctor v2.0.17. In the same commit we also defined a SPEC file for this custom rubygem-asciidoctor RPM package in the "rpm/SPECS" directory in our main project. However, as noted in commit cfde130 of PR git-lfs#71, all the distribution versions based on RHEL 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, and so future releases of the Git LFS client will no longer build packages for them. This change means we will not need to build and install a custom RPM package for Asciidoctor any more, because there are rubygem-asciidoctor packages available in the Extra Packages for Enterprise Linux (EPEL) collection which provide Asciidoctor v2.0.15 or higher for each of the RHEL/CentOS 8, RHEL/Rocky Linux 9, and RHEL/Rocky Linux 10 platforms. We therefore update our Dockerfiles for these platforms to install the rubygem-asciidoctor package. As this package is available from the EPEL collection, we first need to enable the PowerTools (for RHEL/CentOS 7) or CodeReady Linux Builder (CRB) repository, and then install the EPEL package, before installing the rubygem-asciidoctor package. See, for reference: https://docs.fedoraproject.org/en-US/epel/getting-started/ https://packages.fedoraproject.org/pkgs/rubygem-asciidoctor/rubygem-asciidoctor/ Once this PR is merged, we can then update the "rpm/build_rpms.bsh" script in our main project so it skips trying to build or install a custom RPM package for Asciidoctor, and we can remove the corresponding SPEC file for that package as well.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
In commit e828a95 of PR git-lfs#3444 we updated our Makefile so it would pass any linker flags defined in the LDFLAGS environment variable to the Go linker to be passed on to the external system linker. To do this we define the EXTRA_LD_FLAGS Makefile variable, if it is not already defined, with the Go linker's -extldflags option and the value of the LDFLAGS environment variable as the parameter to that option. The EXTRA_LD_FLAGS variable is then included in the LD_FLAGS Makefile variable, which is supplied as the parameter value of the Go compiler command's -ldflags option in the definition of our BUILD Makefile variable. The "go build" compiler command passes the value of its -ldflags option to the "go link" command, which in turn should pass the value of its -extldflags option to the external linker. At present, we enclose the entire value of the -ldflags option in quotation marks, so the full set of arguments from our LD_FLAGS variable is correctly passed to the "go build" command as a single parameter, and then expanded into a set of arguments for the "go link" command. However, we do not enclose the value of the LDFLAGS environment variable in quotation marks, so if it contains multiple arguments for the external linker, only the first is treated as the parameter of the -extldflags option and the remainder are incorrectly considered to be options to the "go link" command. In PR git-lfs/build-dockers#71 and in subsequent commits in this PR we expect to introduce support for the recently-released Red Hat Enterprise Linux (RHEL) 10 and Rocky Linux 10 platform, so that our CI and release GitHub Actions workflows will build RPM packages for this platform. However, our builds of the Git LFS client will not succeed on this platform unless we revise our handling of the LDFLAGS environment variable first, because that environment variable is defined on RHEL/Rocky Linux 10 systems with multiple options, some of which are not valid options for the Go linker. As a result, the "go link" command will fail with an error such as "flag provided but not defined: -Wl,--as-needed" when it tries to parse a -Wl option intended for the external linker as if it were an argument to the Go linker. We therefore update our Makefile's definition of the EXTRA_LD_FLAGS variable so that it enclose any value from the LDFLAGS environment variable in escaped quotation marks. By escaping these delimiters we ensure they will be retained as literals within the single parameter passed for the -ldflags option and not terminate that parameter prematurely. Instead, the value they enclose will now be passed as single parameter for the -extldflags option. We also take the opportunity to replace the curly braces around the LDFLAGS variable name with parentheses, which is the newer style of Makefile variable reference. Note that, in practice, the value we pass to the -extldflags option will be ignored because the Go compiler command does not need to invoke an external linker, since our code no longer imports the "C" pseudo- module nor makes any direct calls to C functions. Our last remaining C code was removed in commit c65ea86 of PR git-lfs#4387. However, for the moment we retain support in our Makefile for the use of the -extldflags option with any system-defined linker arguments in case we have need to resort to the use of C code again in the future.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit 23fbfe8 of PR git-lfs#5911, since all the distribution versions based on Red Hat Enterprise Linux (RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for these platforms or build packages for them. Because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we removed the Dockerfile we used to build packages for the RHEL/CentOS 7 and SLES 12 platforms in commit git-lfs/build-dockers@cfde130 of PR git-lfs/build-dockers#71. We can now also remove the entries for these platforms from the list of our supported Linux distribution versions in the DistroMap Ruby class source file, which is utilized by several scripts run by our GitHub Actions release workflow jobs when building and naming the Linux packages we publish on Packagecloud.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit 23fbfe8 of PR git-lfs#5911, since all the distribution versions based on Debian 10 ("buster") for which we previously built Debian packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for this platform or build packages for it. Because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we removed the Dockerfile we used to build packages for the Debian 10 platform in commit git-lfs/build-dockers@04829f9 of PR git-lfs/build-dockers#71. We can now also remove the entries for this platform from the list of our supported Linux distribution versions in the DistroMap Ruby class source file, which is utilized by several scripts run by our GitHub Actions release workflow jobs when building and naming the Linux packages we publish on Packagecloud.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
Rocky Linux 10.0 was recently released, following the release last month of RHEL (Red Hat Enterprise Linux) 10.0, and because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we added a Dockerfile we can use to build packages for the RHEL/Rocky Linux 10 platform in commit git-lfs/build-dockers@cc16329 of PR git-lfs/build-dockers#71. We can now also add entries for this platform to the list of our supported Linux distribution versions in the DistroMap Ruby class source file, which is utilized by several scripts run by our GitHub Actions release workflow jobs when building and naming the Linux packages we publish on Packagecloud.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit 23fbfe8 of PR git-lfs#5911, since all the distribution versions based on Red Hat Enterprise Linux (RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for these platforms or build packages for them. Because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we removed the Dockerfile we used to build packages for the RHEL/CentOS 7 and SLES 12 platforms in commit git-lfs/build-dockers@cfde130 of PR git-lfs/build-dockers#71. We then also removed the entries for these platforms from the list of our supported Linux distribution versions in the DistroMap Ruby class source file, which is utilized by several scripts run by our GitHub Actions release workflow jobs when building and naming the Linux packages we publish on Packagecloud. Previously, we removed support for the RHEL/CentOS 6 platform in commit d69e28d in PR git-lfs#4328. However, our "docker/run_dockers.bsh" shell script still references these platforms in its comments, so we update that script now to provide more up-to-date usage examples. As well, we update the test data in the Ruby RSpec script we use to validate the DistroMap Ruby class source file, so that the test data now aligns more closely with our current list of supported Linux distribution versions. Note, though, that this change does not affect the behaviour of either the test script or the DistroMap source file.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
In PR git-lfs#5054 we updated the source files of our manual pages from the Ronn format to the AsciiDoc format, which necessitated changing our Linux package build processes to use the Asciidoctor Ruby gem to generate manual pages in Roff and HTML formats. At the time, an RPM package for a 2.0.x version of the Asciidoctor Ruby gem was not easily available for all the platforms based on Red Hat Enterprise Linux (RHEL) that we supported, particularly RHEL/CentOS 7, so in commit db9a821 of PR git-lfs#5054 we updated the "rpm/build_rpms.bsh" script to build and install a custom RPM package with Asciidoctor v2.0.17. In the same commit we also defined a SPEC file for this custom rubygem-asciidoctor RPM package in the "rpm/SPECS" directory. However, we have now removed the Dockerfile we used to build packages for the RHEL/CentOS 7 and SLES 12 platforms in commit git-lfs/build-dockers@cfde130 of PR git-lfs/build-dockers#71, because all the distribution versions based on RHEL 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, and so future releases of the Git LFS client will no longer build packages for them. Further, in PR git-lfs/build-dockers#73 we updated the Dockerfiles we use to build RPM packages of the Git LFS client on the RHEL/CentOS 8, RHEL/Rocky Linux 9, and RHEL/Rocky Linux 10 platforms so that the rubygem-asciidoctor package is installed before the final command in the Dockerfiles is run. This rubygem-asciidoctor package provides Asciidoctor v2.0.15 or higher, so we no longer need to build and install a custom RPM package in order to use Asciidoctor to generate manual pages formatted in Roff and HTML. We can therefore now delete our custom SPEC file for the rubygem-asciidoctor package, and also simplify our "rpm/build_rpms.bsh" script by removing the section which built and installed our custom RPM package if the "asciidoctor" command was not found in a given Docker container image for an RHEL-based platform.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 19, 2025
In commit e4e5ada of PR git-lfs#5882 we added an initial check to the t/t-clone.sh test script which detects whether libcurl is linked against the legacy libnss3 library on Linux, and if so, sets a GIT_LIBNSS variable. We then check that variable at the start of several tests in the script, and if it is set, skip performing the tests. This workaround was introduced because the libnss3 library rejects TLS/SSL certificates which have both an Extended Key Usage attribute for TLS Web Server Authentication and a Basic Constraint setting of "CA:TRUE", and the self-signed certificate used by our lfstest-gitserver utility program has both attributes, so our tests would otherwise fail. The only platform on which our tests run which used the legacy libnss3 library was the one based on Red Hat Enterprise Linux (RHEL) 7. All the distribution versions based on RHEL 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, and so future releases of the Git LFS client will no longer build packages for them. We therefore removed the Dockerfile we used to build packages for the RHEL/CentOS 7 and SLES 12 platforms in commit git-lfs/build-dockers@cfde130 of PR git-lfs/build-dockers#71. As well, in a prior commit in this PR we removed the entries for these platforms from the list of our supported Linux distribution versions in the DistroMap Ruby class source file, which is utilized by several scripts run by our GitHub Actions CI and release workflow jobs. Since our CI and release workflows will no longer run on any platforms where libcurl is linked against the legacy libnss3 library, we can now also remove the checks for the libnss3 library from our t/t-clone.sh test script.
chrisd8088
added a commit
to chrisd8088/build-dockers
that referenced
this pull request
Jun 19, 2025
In PR git-lfs/git-lfs#5054 we updated the source files of the manual pages for the Git LFS client from the Ronn format to the AsciiDoc format, which necessitated changing our Linux package build processes to use the Asciidoctor Ruby gem to generate manual pages in Roff and HTML formats. At the time, an RPM package for a 2.0.x version of the Asciidoctor Ruby gem was not easily available for all the platforms based on Red Hat Enterprise Linux (RHEL) that we supported, particularly RHEL/CentOS 7, so in commit git-lfs/git-lfs@db9a821 of PR git-lfs/git-lfs#5054 we updated the "rpm/build_rpms.bsh" script in our main project's repository to build and install a custom RPM package with Asciidoctor v2.0.17. In the same commit we also defined a SPEC file for this custom rubygem-asciidoctor RPM package in the "rpm/SPECS" directory in our main project. However, as noted in commit cfde130 of PR git-lfs#71, all the distribution versions based on RHEL 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, and so future releases of the Git LFS client will no longer build packages for them. This change means we will not need to build and install a custom RPM package for Asciidoctor any more, because there are rubygem-asciidoctor packages available in the Extra Packages for Enterprise Linux (EPEL) collection which provide Asciidoctor v2.0.15 or higher for each of the RHEL/CentOS 8, RHEL/Rocky Linux 9, and RHEL/Rocky Linux 10 platforms. We therefore update our Dockerfiles for these platforms to install the rubygem-asciidoctor package. As this package is available from the EPEL collection, we first need to enable the PowerTools (for RHEL/CentOS 7) or CodeReady Linux Builder (CRB) repository, and then install the EPEL package, before installing the rubygem-asciidoctor package. See, for reference: https://docs.fedoraproject.org/en-US/epel/getting-started/ https://packages.fedoraproject.org/pkgs/rubygem-asciidoctor/rubygem-asciidoctor/ Once this PR is merged, we can then update the "rpm/build_rpms.bsh" script in our main project so it skips trying to build or install a custom RPM package for Asciidoctor, and we can remove the corresponding SPEC file for that package as well.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jun 20, 2025
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit 23fbfe8 of PR git-lfs#5911, since all the distribution versions based on Red Hat Enterprise Linux (RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for these platforms or build packages for them. Because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we removed the Dockerfile we used to build packages for the RHEL/CentOS 7 and SLES 12 platforms in commit git-lfs/build-dockers@cfde130 of PR git-lfs/build-dockers#71. We then also removed the entries for these platforms from the list of our supported Linux distribution versions in the DistroMap Ruby class source file, which is utilized by several scripts run by our GitHub Actions release workflow jobs when building and naming the Linux packages we publish on Packagecloud. Previously, in commit ff36182 of PR git-lfs#4328, we removed support for distribution versions based on the Debian 8 ("jessie") platform, including Ubuntu 14.04 ("Trusty Tahr") and Linux Mint 17.1 ("Rebecca"). However, some of the installation examples in our "INSTALLING.md" page still reference these platforms, so we update these exmaples now with more contemporary Linux distribution versions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates the set of
Dockerfiles we use to build Linux packages for the Git LFS client by removing support for RHEL/CentOS 7 and Debian 10, and adding support for RHEL/Rocky Linux 10.Note that in a subsequent PR we will update our
Dockerfiles to use the latest version of Go.RHEL/Rocky Linux 10
Rocky Linux 10.0 was recently released, following the release last month of RHEL (Red Hat Enterprise Linux) 10.0, and because we anticipate making a v3.7.0 release of the Git LFS client in the near future, we now add a
Dockerfilewe can use to build packages for the RHEL/Rocky Linux 10 platform.Except for the name of the base image in the
FROMstatement, this newDockerfileis identical to the one for the RHEL/Rocky Linux 9 platform.RHEL/CentOS 7 and SLES 12
As announced with the v3.6.0 release of the Git LFS client, and as noted in commit git-lfs/git-lfs@23fbfe8 of PR git-lfs/git-lfs#5911, since all the distribution versions based on Red Hat Enterprise Linux (RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which we previously built RPM packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for these platforms or build packages for them.
We therefore now remove the
Dockerfilewe used to build packages for the RHEL/CentOS 7 and SLES 12 platforms.Debian 10 ("buster")
As also announced with the v3.6.0 release of the Git LFS client, and as noted in commit git-lfs/git-lfs@23fbfe8 of PR git-lfs/git-lfs#5911, since all the distribution versions based on Debian 10 ("buster") for which we previously built Debian packages have now reached the end of their standard LTS (Long-Term Support) periods, future releases of Git LFS will no longer provide support for this platform or build packages for it.
We therefore now remove the
Dockerfilewe used to build packages for the Debian 10 platform.Script Updates
We are removing the
Dockerfilewe used to build RPM packages for the RHEL/CentOS 7 platform, and in 2019 we removed theDockerfilewe used to build Debian packages for the Debian 7 platform in commit 5e7bf33 of PR #26.Several of our shell scripts still reference these platforms in their comments, however, so we update those scripts now to provide more up-to-date usage examples.