On Fri, 13 Jan 2023 11:17:29 -0500 John Blinka <[email protected]> wrote:
> On Thu, Jan 12, 2023 at 12:54 PM Laurence Perkins <[email protected]> > wrote: > > > I’m not sure if I’m doing something horribly wrong, or missing something > > blindingly obvious, but I’ve just had to boot a rescue shell yet again, so > > I’m going to ask. > > > > > > > > To save time and effort, I have my big, powerful machine create > > binpackages for everything when it updates, and then let all my smaller > > machines pull from that. It works pretty well for the most part. > > > > I do something quite similar, but have never had a glibc problem. Maybe the > problem lies in differences between the specific details of our two > approaches. > > I have 3 boxes with different hardware but identical portage setup, > identical world file, identical o.s., etc, even identical CFLAGS, CPPFLAGS > and CPU_FLAGS_X86 despite different processors. Like you, I build on my > fastest box (but offload work via distcc), and save binpkgs. After a world > update (emerge -DuNv —changed-deps @world) , I rsync all repositories and > binpkgs from the fast box to the others. An emerge -DuNv —changed-deps > —usepkgonly @world on the other boxes completes the update. I do this > anywhere from daily to (rarely) weekly. Portage determines when to update > glibc relative to other packages. There hasn’t been a problem in years with > glibc. > > I believe there are more sophisticated ways to supply updated portage trees > and binary packages across a local network. I think there are others on > the list using these more sophisticated techniques successfully. Just a > plain rsync satisfies my needs. > > It’s not clear to me whether you have the problem on your big powerful > machine or on your other machines. If it’s the other machines, that > suggests that portage knows the proper build sequence on the big machine > and somehow doesn’t on the lesser machines. Why? What’s different? > > Perhaps there’s something in my update frequency or maintaining an > identical setup on all my machines that avoids the problem you’re having? > > If installing glibc first works, then maybe put a wrapper around your > emerge? Something that installs glibc first if there’s a new binpkg then > goes on to the remaining updates. > > Just offered in case there’s a useful hint from my experience - not arguing > that mine is the one true way (tm). > > HTH, > > John Blinka > > > In case it is not clear what the underlying problem is: Slow machine updates and is on the same set of packages as the fast machine. Fast machine updates glibc to a new version at time T1 Fast machine updates app-arch/xz-utils to a new version at time T2. This version of xz CAN have glibc symbols from the very newest glibc version that was merged at time T1. Everything is fine on the fast machine. Now the slow machine starts its update process at a time T3 > T2. The list of packages includes glibc AND xz-utils, however xz-utils is often pulled in before glibc which ends in a disaster. Now you have an xz decompressing tool on your slow machine that cannot run, because some library symbols from glibc are missing (because glibc was not merged yet), and you're pretty much stuck in the middle of the update with a broken system. I have seen this kind of behaviour only when I have not updated for a very long time the slow machine (i.e. no update for a year). Anyway I think a reasonable default for emerge would be to merge glibc as early as possible, because all other binary packages could have been built with the newer glibc version, and could potentially fail to run on the slow machine until glibc is updated. Hope that clears up what happens, and why it fails to update / breaks the slow machine. Andreas
