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.updates something that's needed for handling updates and that's it, stuck. If I'm lucky it's a compile tool, not one for handling binpackages and I can just tell it to do the glibc package next. Quite often though it's something like tar that's
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.
But when there's a glibc update I have to specifically install it first. If I don't, then about half the time emerge decides that because it doesn't have to worry about build dependencies for binpackages, it can obviously update glibc last... Then it
Think it's worth a feature request to have emerge prioritize glibc as high up in the list as it can when installing things? Or am I the only one who runs into this?
LMP
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.
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 lessermachines. Why? What’s different?</div><div dir="auto"><br></div><div dir="auto">Perhaps there’s something in my update frequency or maintaining an identical setup on all my machines that avoids the problem you’re having?</div><div dir="auto"><br></
<div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Justoffered in case there’s a useful hint from my experience - not arguing that mine is the one true way (tm).</div><div dir="auto"><br></div><div dir="auto">HTH,</div><div dir="auto"><br></div><div dir="auto">John Blinka</div><blockquote class="gmail_
On Thu, Jan 12, 2023 at 12:54 PM Laurence Perkins <lperkins@openeye.net> 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
That's not a terrible idea. Although running emerge twice every time in order to check would slow things down considerably. Probably better to
just get it through my thick head to update core libraries first.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 302 |
Nodes: | 16 (2 / 14) |
Uptime: | 100:04:15 |
Calls: | 6,767 |
Calls today: | 5 |
Files: | 12,295 |
Messages: | 5,376,419 |
Posted today: | 1 |