handling "=" dependencies...

eccerr0r · Posted: Sun Mar 16, 2025 7:29 am Post subject: handling "=" dependencies...

When there's a

DEPEND="dev-libs/icu:="

in an ebuild, I take it that if icu gets rebuilt for upgrade, that ebuild package must also be rebuilt.

What happens if icu gets rebuilt and then the computer crashes/reboots/... immediately after icu finishes? Does portage atomically save up and build all packages with the = operator and installs them all at the same time?

I'm trying to figure out why my machine seems to have a clean emerge --emptyuse @world but doing --update --deep --newuse @world fails reporting it can't find a package that has been removed from the tree, specifically icu-74. Is it possible for a package to no longer want to be rebuilt if icu-76 got rebuilt and a system crash occurs, and emerge is restarted from the top? Would this be a bug? Is there a tool to fix this?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

bunder · Bodhisattva Joined: 10 Apr 2004 Posts: 5954

If emerge crashes, sometimes you can get it back with emerge --resume, but if you ran another instance of emerge, or if it's being called from another tool that calls emerge in multiple steps (like crossdev or maybe revdep-rebuild), then that might not be enough to finish what was being done at the time... it's pretty situational.

That said, to answer your other question, you might be able to use a combination of equery depends and equery depgraph to find out what wants the old icu, so you can selectively upgrade it, hopefully giving you a clean emerge --update @world afterwards.

Cheers
_________________

eccerr0r · Posted: Sun Mar 16, 2025 10:10 am Post subject:

Yeah was afraid of that, had to emerge other stuff to fix the stoppages from fixing configs or downloading files. Seems there should be a better way to handle these.

The reverse dependencies of icu is very very bad on a Gnome machine because it goes through a lot of crap, and glib also seems to have "=" dependencies as well so that trees up even more. I was hoping @preserved-rebuild was enough but don't think it is. revdep-rebuild I don't know if it will work... depgraph is promising but a lot... but at least it's probably still less than the restart of --emptytree that I did again... 1300 packages...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

sam_ · Developer Joined: 14 Aug 2020 Posts: 2224

The VDB records the last subslot a package was built against, so running emerge -a -uvDU @world (or whatever) again should queue the remaining things for rebuild.

eccerr0r · Posted: Sun Mar 16, 2025 4:38 pm Post subject:

For some reason it doesn't seem to want to upgrade them, not sure why -uDN @world doesn't want to touch these packages (backtrack count is like something from 2 to 5 and says "installed" versus "queued for upgrade") but --emptytree will provide a solution without backtracking. I got a couple to rebuild by manually rebuilding (specifically got qtcore 5.15.14 upgraded to 5.15.16 and its co-dependencies) but ran into that reverse dependency hell with glib.

I'm --emptytree again so if it dies again without resolving the issue, (it's a 2C4T laptop so it will be a while even with distcc help) i'll try to post a more detailed diagnostic... I suppose the --emptytree isn't all a waste other than it failing, because I never did the --emptytree when migrating to profile 23.

(hmm... this laptop might be a good candidate for chroot build because it and my 10 core xeon are both ivybridge...)

Note: portage dying includes distfiles missing, i tried to set up al of my machines to fetch distfiles from my server and sometimes it doesn't have the package downloaded in time.)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

I think you've misread portage output as if something still needed the old icu libraries they would be preserved and you would get a message there were preserved libs. Can you check is an update to icu indeed happened or this was just a rebuild for some reason?

Best Regards,
Georgi

sam_ · Developer Joined: 14 Aug 2020 Posts: 2224

Note also that glib is a distinct case, it doesn't use subslots at all or := deps. I think there's more going on here and hard to say without some proper output.

eccerr0r · Posted: Sun Mar 16, 2025 9:29 pm Post subject:

Well, icu was upgraded to 76 and a whole bunch of other stuff, when I emerge --update @world, wanted to re-merge icu-74 because it was missing...of course it's missing, it was just updated to 76. However there were a bunch of conflicts with these consumers of icu stating they can't be updated for whatever reason -- there were some that would (and hence be linked with icu-76) but others were not tagged.

IIRC it was one of glib's dependencies that had an := dependency and that dependency was tied to icu. So both that dependency and glib needed to be upgraded. But yeah it wasn't glib that was the problem, looks like evolution-data-server is a problem...

Hu · Administrator Joined: 06 Mar 2007 Posts: 23210

gnome-extra/evolution-data-server has a very complicated subslot, which a comment in the ebuild explains as: subslot = libcamel-1.2/libebackend-1.2/libebook-1.2/libebook-contacts-1.2/libecal-2.0/libedata-book-1.2/libedata-cal-2.0/libedataserver-1.2/libedataserverui-1.2/libedataserverui4-1.0 soname version. I think the value you see is plausible, and is in the VDB because Portage correctly copied the then-live subslot of evolution-data-server into the VDB dependency data for folks.

I see that there are no newer versions of dev-libs/folks available. Perhaps the way you invoked emerge caused it to skip folks since that would be a rebuild at the same level, rather than an update. However, this is pure speculation on my part.

If folks is not upgraded, then Portage wants old evolution-data-server, which wants old icu. So I think everything comes down to "Why is Portage not choosing to re-emerge folks?"

eccerr0r · Posted: Sun Mar 16, 2025 11:47 pm Post subject:

Ah, now that makes sense, thanks.

Still is weird - folks is a dependency of @world as seen in the stack posted:

@world @selected gnome gnome-core-apps gnome-contacts folks

The other curious thing is the:
(dependency required by "dev-libs/folks-0.15.9::gentoo[eds]" [installed])
(dependency required by "gnome-extra/gnome-contacts-46.0::gentoo" [ebuild])
... not sure what the significance of that is. In fact that might be the missing link to figuring what's going on here...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

eccerr0r · Posted: Mon Mar 17, 2025 4:52 am Post subject:

I usually have --keep-going on any run, but inevitably there will be problems that will stop the merge. I rarely am successful to use --resume so typically I end up re-starting emerge from the start just as I initially started the first time.

This emptytree run has also ended prematurely a few times already, which is not a good sign... will probably need to restart it again and hope I get a different result after fixing the issues that caused them fixed...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

eccerr0r · Posted: Mon Mar 17, 2025 7:27 am Post subject:

sam_ · Developer Joined: 14 Aug 2020 Posts: 2224

The #1 cause of stuff like this is where some installed package can't be rebuilt (often an ebuild missing for it and newer ones are masked or not available for some reason) and Portage maanges to soldier on despite it for a while, then some "event" (like an interruption here) occurs and it can't do so anymore.

What does emerge -pev @world --backtrack=0 say (full output please)?

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

eccerr0r · Posted: Mon Mar 17, 2025 9:57 am Post subject:

FCK... The --emptytree build I was doing despite the intermediate problems (due to --keep-going) have now cleaned up the main problem I'm having and no longer seeing the conflict with e-d-s and icu on update... so this is good (problem gone?) and bad (why did the problem manifest in the first place?).

There is still a new problem with poppler and tracker-miners but since the --emptytree hasn't finished yet, I won't mess with debugging it just yet...it may well self resolve too... going to wait before doing any more experiments.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

Sam's command may still give useful information once emerge is finished.

Best Regards,
Georgi

Hu · Administrator Joined: 06 Mar 2007 Posts: 23210

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

eccerr0r · Posted: Mon Mar 17, 2025 3:00 pm Post subject:

I actually don't mind if portage fails due to missing distfiles, that wasn't ever an issue, in fact I sort of expect files to be missing (cache miss)... Just need to rerun and it should be a cache hit the second time around. Couldn't think of a non-polling method to wait for the file to download so I just let it fail and I'll wait till it's ready.

The original problem is if portage vdb is ever left in an unrecoverable state if it does fail for any reason including missing distfiles. I'm getting conflicting answers...

Funny. I was having problems with emerge --fetchonly --pretend for a while and stopped doing it since it was causing problems hence my current half baked solution. I never figured out what the problem with --fetchonly was, nor if it's still an issue. The current state of the machine I'm working on has --fetchonly working just fine right now, fortunately (or unfortunately if it's worth to debug).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

eccerr0r · Posted: Mon Mar 17, 2025 3:40 pm Post subject:

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2844

eccerr0r · Posted: Mon Mar 17, 2025 3:58 pm Post subject:

TBH I did not use --backtrack=0 but it completed saying (backtrack: 0/20) which as far as I understand means it never backtracked and --backtrack=0 would have given the same results (except saying backtrack: 0/0) ?

And yeah as said before, I did not get any missing ebuild or masked package warnings when I emerge --emptytree like what you have (now that I see your example). Indeed I have run into those issues before and were easy to solve with that diagnostic output, but this one completely baffled me when --emptytree was clean as-is and --update had that confusing conflict hence making a theory that I have database corruption or portage is doing something really wrong outside of what normally happens doing merges either with the corrupt data or worse, without.

Incidentally the machine now --update --deep --newuse @world runs cleanly now with backtrack of 0/20... Argh. I guess I'll never figure out what went wrong here other than resorting to use --emptytree if all else fails and nothing seems wrong.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?