mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 05:16:00 +03:00
[GH-ISSUE #2469] Drop RHEL/CentOS 7 support when EOL #1216
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1216
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gaul on GitHub (Jun 10, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2469
s3fs should consider dropping RHEL/CentOS 7 support when it reaches end-of-life on 30 June 2024. Some benefits:
std::optional,std::string_view, etc.Some downsides:
@juliogonzalez any thoughts about this? Will EPEL updates still work after EOL?
@ggtakec commented on GitHub (Jun 10, 2024):
See also #2328, which contains the same content as this issue.
And about this, I would like to carefully consider the transition to AWS C++.
For example, I am still concerned about the different license, the fact that AWS C++ needs to be built rather than provided as a library, parallel requests, special authentication implementations (such as IBM), etc.
@gaul commented on GitHub (Jun 12, 2024):
Right, C++14 support is necessary for using the SDK but using C++14 doesn't obligate us to use the SDK. Let's discuss that issue when we have a proof of concept and not as part of the RHEL 7 EOL.
@ggtakec commented on GitHub (Jul 1, 2024):
Guthub Actions(CI) tests for CentOS 7 can no longer be cpmpleted(could not use mirror repository).
We need to prepare to remove CentOS 7 from GHA.
@gaul commented on GitHub (Jul 1, 2024):
It will be difficult going forward to maintain CentOS 7 compability without CI. Do you think we should run a 1.95 release now so those users get a final release? Will EPEL still accept packages for this older distro? @juliogonzalez
@juliogonzalez commented on GitHub (Jul 1, 2024):
I can try, at least.
Worst, worst case, I can prepare the package outside EPEL and provide it via the openbuildservice for CentOS7.
It could be interesting, as some companies are going to extend CentOS7 lifecycle, such as SUSE (Liberty Linux) and CIQ (Bridge). Of course being those subscription distributions, there's no way to provide support going forward, but it would be nice to provide a final version.
@juliogonzalez commented on GitHub (Jul 1, 2024):
In case you want to run the tests one more time, this is happening because they remove the repos and moved stuff to the vault. Latest available version at the vault is https://vault.centos.org/7.9.2009/, which contains all required repositories.
@ggtakec commented on GitHub (Jul 2, 2024):
@juliogonzalez @gaul
Please let me know your opinions.
As a test, I created a branch that can run GHA with Vault C7.9.2009.
https://github.com/ggtakec/s3fs-fuse/tree/centos7
(The changes in the repository are a bit brute-force code, but it seems to work correctly.)
You can check the CI results for CentOS7 here:
https://github.com/ggtakec/s3fs-fuse/actions/runs/9759601518/job/26936610009
Would you like to merge this into the main s3fs-fuse repository? (Or would you like to keep it in another branch?)
The source code(mainly scripts, etc.) will still require a branch specifically for CentOS 7, so I don't recommend this, considering the impact on the main code.(You can keep it in my forked repository)
@juliogonzalez commented on GitHub (Jul 2, 2024):
Personally, I'd merge it to
masterto enable the CI for a last 1.95 release which is to be still compatible with CentOS7.That is, of course, if you want 1.95 still compatible with CentOS7 as a last gift for the community.
It will not be part of EPEL7, because it seems they decided no to extend EOL for EPEL7: https://pagure.io/epel/issue/238
But I can easily prepare the package for EPEL7 using the Open Build Service.
So... what do we want to do? 1.95 as last version, or the current released 1.94 as last version?
What I understand from the description is that, for sure, s3fs does not want to keep compatibility or maintain a separate branch for CentOS7, as that will avoid bumping FUSE to v3, or using newer variants of C++.
Let me know what you think.
@ggtakec commented on GitHub (Jul 2, 2024):
I think it would be a good idea to release 1.95 and make it the last version of CentOS 7.
Then, after releasing 1.95, I would like to remove the CentOS 7 support code from the master branch and prepare s3fs-fuse for the next phase(fuse3, etc.).
@gaul
what do you think about this?
@Bhagyashreek8 commented on GitHub (Jul 9, 2024):
@ggtakec Is there any ETA for fuse3 support on s3fs-fuse? On Ubuntu 24.04, building or installing s3fs-fuse without removing Fuse3 is quite challenging.
cc: @nkkashyap
@gaul commented on GitHub (Jul 12, 2024):
@Bhagyashreek8 if you have observations about FUSE3 support please make them in #1159 not here. FUSE3 will likely break the current macOS support so we will need to work with the FUSE-t maintainer.
@gaul commented on GitHub (Jul 12, 2024):
I like this plan. I opened a bug tracking this.
@gaul commented on GitHub (Nov 6, 2024):
CentOS 7 CI removed in
330cb39daf.