I fork here a discussion started as part of About eos5 repos which was on another topic. @evamvako mentioned problems he experienced with EOS packages in the diopside/tag repository having requirements on packages from diopside-depend not yet present in this last repo.
@acontesc answered: “We normally deal with this by version locking EOS and XRootD packages (make sure yum-plugin-versionlock package is installed)”.
I’m a little bit surprised by this answer: I have quite some experience in deploying many applications from YUM and I’ve never seen version locking used as baseline feature, always to deal with exceptions. For me, the EOS team building both repository if I’m right, they should always be in sync in such a way that if you take a snapshot of both repo at the same date (probably an interval of a few minutes!) you don’t have unsatisfied requirements because the version provided in the dependency repository are below the requirements. Any other approach will turn into an operational nightmare, I’m afraid.
I’d appreciate some clarifications on this point. Cheers,
The version locking is trying to effectively solve one very specific issue. I will use some examples for simplification:
EOS is heavily dependent on XRootD version against which it was built on
EOS and XRootD have different release paces
Assuming EOS version X has been released, and is dependent on XRootD version Y.
Both EOS X and XRootD packages are released into the eos and dependencies repositories, let’s assume, for the sake of the exercise, at the same time => if you snapshot the repos right now, all is good
A couple of hours later a new version of XRootD, Y.1, is released, it gets into the dependency repositories and EOS remains at version X; if you take a snapshot now, and not having versionlocking enabled, will result in yum dependency issues during a yum update, because yum will try to bring in the latest XRootD version (Y.1), while EOS still requires Y.
Of course this is an over-simplification of the situation and might not imply this is currently happening if using repo snapshotting (which we do not use, here at CERN).
hello Cristian
I do not disagree with your analysis
but the problem was on
eos-xrootd-5.4.1-1.el8.x86_64
eos-xrootd-0:5.3.100-1.el8.x86_64
where the dependecy of eos-server-x-x-x is stricty on eos-xrootd-5.3.4-1.el8.x86_64
I do not understand as both packages eos-server-x-x-x and eos-xrootd-x-x-x is managed at eos devops level.
Why is no corehert the version dependency of eos-serever vs eos-xrootd and what is on the depend repository for eos-xrootd ?
of course version lock ( specifc exclusion of rpms with problmatic version) could help
but make the seamless update rather complecate as Michel points
You are right, that nowadays you don’t necessarily need the versionlock file at the yum level since we narrow down the dependencies to the exact version number. This was not the case in the past, so we used to use the versionlock file. But even with exact dependencies you still need to version lock the vanilla xrootd-* packages as eos (depending how the rpms are built) will only list the dependency on eos-xrootd. Since you can have xrootd-server and eos-xrootd installed on the same machine and to avoid any complications it would be good to keep them in sync - and this can be most easily achieved with version lock.
Thanks for the clarifications. As we mirror/snapshot all repositories in the middle of the night, the risk of the inconsistency described by Cristi is low. Let’s get more experience with using the EOS repos and moving from one YUM snapshot to another one. As long as you maintain in the dependency repo all the versions required by EOS versions present in the main repo, it should work with the strict version requirement, I agree.