MISSING: libboost_thread-1.89.0_2

[devilsclaw]

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

[sgn]

Python is building

[realsn0w]

could the build system maybe be adjusted to not upload multilib/debug packages before current is 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]

xbps is preventing your computer from being broken when it refuses to install an update

[Folling]

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]

^this

xbps is preventing your computer from being broken when it refuses to install an update

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]

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 multilib or debug.

How it works is that xbps-rindex adds packages to the repository index. Whenever a package is build that happens and when xbps-rindex sees 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-rindex will 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-rindex is 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 debug and multilib.

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

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 32bit and dbg packages 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 version xbps-pkgdb -m hold foo-dbg or by hand selecting what to update which would exclude -32bit or -dbg packages that require a version that is not in the "public" index.

[Folling]

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]

@Duncaen thanks a lot for the extensive reply :)

Its a tradeoff that we have to kind of live with? Until some contributes a solution?

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]

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]

What a wonderful way to treat people part of your community and to build a sustainable and fostering ecosystem that everyone can benefit from. Your entire system was non-upgradable for 4 days, you even had people willing to fix it and this is how you choose to respond, belittling and without the option for response, not even acknowledging the offer for support.