Repository navigation
MISSING: libboost_thread-1.89.0_2 #58120
Description
Is this a new report?
Yes
System Info
Void 6.17.8_1 x86_64 GenuineIntel uptodate rrrrrrmmdn
Package(s) Affected
libboost_thread-1.89.0_2
Does a report exist for this bug with the project's home (upstream) and/or another distro?
No response
Expected behaviour
update to work
Actual behaviour
update fails
I just tried to do a system update and its throwing
MISSING: libboost_thread-1.89.0_2
ERROR: Transaction aborted due to unresolved dependencies.
Steps to reproduce
xbps-install -Su
Activity
sgn commentedon Dec 8, 2025
Python is building
realsn0w commentedon Dec 8, 2025
could the build system maybe be adjusted to not upload
multilib/debugpackages beforecurrentis also done building?this keeps happening during large rebuilds and gets really annoying over time.
i get that these things take time but i'd really prefer it if my PC didn't become half-broken every time buildbot is overloaded.
classabbyamp commentedon Dec 8, 2025
xbps is preventing your computer from being broken when it refuses to install an update
Folling commentedon Dec 8, 2025
I don't really see how this is preventing anything. What @realsn0w meant is that xbps uploads partial state during building. Looking at their screenshot, revision 1 is pushed for libboost_thread, but revision 2 is already pushed for libboost_thread-dbg. This causes errors when you want to install updates because it finds a broken state in the build system.
Instead the build system should first build everything, then push everything. As opposed to building debug symbols and associated 32-bit libraries in parallel and pushing them separately.
realsn0w commentedon Dec 8, 2025
^this
the issue is not xbps' behavior, but rather the fact that packages with broken dependencies are hitting the public mirrors at all
that's not something that should happen in any capacity
randomly being unable to install/update packages is a disaster if you rely on a system in any capacity
especially since you can't fix it yourself given that e.g. all up-to-date tier 2 mirrors are shipping equally borked packages
given that this is far from the first time this has happened i'd like to know why this is handled like this.
was this just an oversight that didn't affect enough people to be noticed so far?
is it intended like this and "occasionally users are unable to install software" considered an acceptable tradeoff? if yes why?
thanks
Duncaen commentedon Dec 8, 2025
Its really not how this works or how its supposed to work. We don't "push" or add packages to the repository manually or only to
multilibordebug.How it works is that
xbps-rindexadds packages to the repository index. Whenever a package is build that happens and whenxbps-rindexsees an inconsistency with shared libraries it will put the repository in "staging" mode, which means all packages are held back until all inconsistencies are resolved.They are being resolved one by one as the builds progress and when everything is finished building
xbps-rindexwill add all the packages to the "public" repository.When a repository is in staging mode it means that there can be multiple versions of a package, the old version and potentially the updated version, this is required so that you can actually build packages against the updated version.
What causes the issue from this thread is that
xbps-rindexis currently only aware of one repository at a time.Which mans that it only puts the repository that holds the conflicting package into staging mode, not the other repositories like
debugandmultilib.Its a tradeoff that we have to kind of live with? Until some contributes a solution?
You can still kind of install packages and "update" your system (there won't be new updates until everything is built.)
You'll just have to work around the
32bitanddbgpackages at the moment since xbps is also not smart enough to "resolve" that conflict on its own by not trying to update those packages. You could hold them at the versionxbps-pkgdb -m hold foo-dbgor by hand selecting what to update which would exclude-32bitor-dbgpackages that require a version that is not in the "public" index.Folling commentedon Dec 9, 2025
The following message may be read as rude, it's not intended to be. Open source work is often thankless and I understand that you're all here on your free time & dime. This is an issue of system, not of person. However I simply do not see any reason to sugarcoat my opinion here. Please read it with kindness in your heart.
Thanks for clarifying, but it's been multiple days now that I have been unable to update my system.
The proposed workaround is not an option for me. I need the installed packages to match their debug versions for my everyday work. I also do not want to invest manual labour to work around an issue that should really be fixed in code. I especially do not want to write a fragile script that could brick my system at any time were I to make a mistake or were the void ecosystem to have a regression to avoid said manual labour.
"Tradeoff" implies there's a benefit to the current approach. I do not see that being the case here. Maybe I'm missing something.
Really, having to say that we can only "kind of" install packages and putting "update" in quotes should be evidence enough for the importance of this issue.
I do not have time to invest into fixing xbps-rindex at the moment. But I would be willing to contribute virtual hardware or monetary support to increase the capacity of the build system, which should at least reduce the amount of time my system, servers, and containers are non-upgradable when large packagetrees are being built.
realsn0w commentedon Dec 9, 2025
@Duncaen thanks a lot for the extensive reply :)
i might look into this then
is this something that a PR could just be submitted for, or would you prefer discussing it in an issue/elsewhere first?
didn't see a contributing guide in the xbps repo
ahesford commentedon Dec 10, 2025
If things aren't working again in five minutes, just wait longer.
You can live with it, fix it, or find a distribution that satisfies your needs. The choice is yours.
Folling commentedon Dec 10, 2025
classabbyamp commentedon Dec 10, 2025
This was never a problem that could be solved instantly. once the builds were in motion, they need to finish to resolve the issue. However, the "entire system" was not non-upgradable, just a few packages. The rest of the repo was fine.
A fix for the future is in progress (void-linux/xbps#662), but it's a non-trivial change and requires some thought to implement correctly and robustly.
ahesford commentedon Dec 11, 2025
Ultimately, this is all another facet of the fundamental caveat of a rolling-release distribution: if you care about specific package versions, at some point your workflow will break. If you can't adapt to this, you should not be using a rolling release.
The fact that multilib and debug repos are not staged just means that, during the rebuild, you suddenly care about specific package versions if, and only if, you want to install a debug package in that time interval. Multi-repo staging closes this window.
What it will not do is address the inability to update while long rebuilds are in process. Right now, you try to update and XBPS refuses because it can't reconcile dependencies. With multi-repo staging, you try to update and are just told nothing is available. The end result is the same. Frustration is conserved.