-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Where to get git on AL9 #110
Comments
I would minimize the extra work and stay with the system version. If and when git adds a compelling new feature, and that feature is missing in the system version, we can switch to a CSAID or Mu2e-maintained install. |
From Seth Graham:
This sounds definitive. The OS people do not plan to keep git up to date, end of story. |
I would wait to change source until the version in spack is at least as
recent as the version provided by the OS.
…On Mon, Jun 24, 2024 at 9:42 AM Rob Kutschke ***@***.***> wrote:
From Seth Graham:
Our support for git is "we install whatever the OS provides." RHEL does
not to do major version updates within an OS release, so the /usr/bin/git
available now will remain about the same for RHEL9's entire lifecycle. It
will get bug fixes and security updates backported to it.
So if you need to change versions more often than that.. you should
probably continue to use the version in cvmfs.
This sounds definitive. The OS people do not plan to keep git up to date,
end of story.
—
Reply to this email directly, view it on GitHub
<#110 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABAH572D53TDLZWHIRGZA5DZJBD7HAVCNFSM6AAAAABJ2BCRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWHE4DSMRQGM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
David Brown ***@***.***
Office Phone (510) 486-7261
Lawrence Berkeley National Lab
M/S 50R5008 (50-6026C) Berkeley, CA 94720
|
Yes. I think we all agree on that After discussing with Kyle and Marc, I have opened an issue in a CSAID issue tracker to discuss this and other products that we used to get via UPS, suchs as gitflow, gdb, valgrind ... . Let's mostly move this conversation to that issue
We can use the current issue if we want to discuss some things in house before presenting a consensus to Kyle and Marc. |
There is no rush on this - it's a question of how to avoid git atrophy with time.
On the SL7 GPVM nodes the system git was ancient, v1.8.3.1. That was OK since we got an up-to-date git from UPS. We did the UPS setup in mu2einit.
On AL9 the system git is 2.43.0, which fairly recent. We are not currently loading a version of git in our spack view. As it happens the most recent version in /cvmfs/mu2e.opensciencegrid.org/packages/git is 2.40.0, so a little older than the system.
We should decide what we want moving forward. Do we want CSAID to keep the system git reasonably up to date? Or do we want to include it in our spack view? Do we want to make this decision together with the online group or on our own?
When discussing this, do we need to consider control over the timing of new git releases and the possibility of the need for a rollback? We could decide that git is mature enough that we can ignore this. In that case, asking the system people to do it is the least work for us.
I don't know what the AL9 people at the lab intend to do with versions of the system git moving forward. I have put in a ticket to learn about it RITM2140247 .
The text was updated successfully, but these errors were encountered: