On Mon, Sep 18, 2023 at 12:13 PM Alan McKinnon <alan.mckin...@gmail.com> wrote:
> > > If webkit-gtk is the only big package, have you considered: > > emerge -1v webkit-gtk && emerge -avuND @world? > > > What you have is not a portage problem. It is a orthodox parallelism > problem, and I think you are thinking your constraint is unique in the work > - it isn't. > With parallelism, trying to fiddle single nodes to improve things overall > never really works out. > > Just my $0.02 > > > Alan > I use this idea, but it requires (for me) a more sophisticated implementation. As is, it pulls in webkit-gtk-x.y.z and webkit-gtk-x.y.z-r410 simultaneously - for my portage setup. I don’t have the memory to handle both at the same time. It’s guaranteed to crash on my system. Instead, I do a preliminary emerge -p<etc>, saving the specific package builds to a file. I then inspect the file to see what portage wants to do. Too often, the file contains webkit-gtk-x.y.z and webkit-gtk-x.y.z-r410 in sequence, usually preceded and followed by other packages. Portage always wants to build both versions simultaneously - guaranteed crash for me. Instead of invoking emerge, I write a little bash script to emerge the preceding packages in parallel, followed by a serial webkit-gtk-x.y.z, followed by a serial webkit-gtk-x.y.z-r410, and then finally all the remaining packages. Four emerge invocations in sequence. The script builds specific versions, ie, =net-libs/webkit-gtk-x.y.z, to ensure it builds only 1 package at a time. It’s trivial to write. A problem arises when splitting up builds as you suggest. Emerge has its own ideas about what it’s going to do - and in what sequence. When you try to impose a build order not of its making, emerge will often do something unintuitive and frustrating to you. I’ve learned to respect its sequencing. This technique keeps portage happy and predictable by using its sequencing. It gives me reliable overnight unattended upgrades. John Blinka >
