Void-packages: kde5-baseapps is not installable

[ericonr]

System

• package: kde5-baseapps-20.04.3_1

Expected behavior

I install it and I get its dependencies.

Actual behavior

I try to install it and xbps-install errors out without any error message. Running with debug generates a huge log: https://gist.github.com/ericonr/b4be938b806523064008e7c8ce638227

I tried building the meta package locally and got the same error. I also tried installing each application individually and that worked.

Steps to reproduce the behavior

xbps-install kde5-baseapps

@Johnnynator and @Duncaen, since I think this is some sort of bug in XBPS as well.

[abenson]

dolphin and dolphin-plugins depend on each, and so it breaks when resolving auto deps.

[abenson]

Simple test template demonstrates the same issue:

# Template file for 'dolphinasadep'
pkgname=dolphinasadep
version=1
revision=1
build_style=meta
depends="dolphin"
short_desc="Dolphin is a dep"
maintainer="Andrew Benson <[email protected]>"
license="GPL-3.0-or-later"
homepage="https://voidlinux.org"

[ericonr]

Installing dolphin separately and then kde5-baseapps works, because then XBPS knows how to solve the dependencies. I guess this should be solved somewhere in XBPS.

This is probably the issue in shlibs:

libdolphinvcs.so.5 dolphin-plugins-20.04.2_1

This library is provided by dolphin, not dolphin-plugins. Even though dolphin provides it, during the build it's found and dolphin-plugins is pulled in as a dependency.

[Johnnynator]

Yes, that shlib entry is wrong, Should be removed and dolphin rebuild.

[ericonr]

@Johnnynator I'm making a PR for it.

[martindamianfernandez]

thanks stuff to report right now have got my account again., see you on irc. im hechos...

[ericonr]

@Duncaen what do you think is the best way to solve this?

[Duncaen]

Not really sure what exactly the issue is, xbps should handle cyclic dependencies, but I couldn't come up with a test case yet.
That said, xbps-src doesn't support cyclic dependencies and this looks like a mistake.

[ericonr]

@Duncaen it definitely is a mistake! #23626 fixes it. Would just be nice if XBPS could have a better error message during an install or better error checking during package creation.

[Chocimier]

mistake

I didn't checked which package contain library when merging plugins, sorry.

While here, I have naive question raising since some time: why do we need common/shlibs at all, rather than 04-generate-runtime-deps querying xbps index for which installed package provides library?

[Duncaen]

While here, I have naive question raising since some time: why do we need common/shlibs at all, rather than 04-generate-runtime-deps querying xbps index for which installed package provides library?

It records the minimum version that provides the SONAME, which makes it easier to downgrade and partially update things.

If you start to use xbps-query to get the current version of a package providing the SONAME in the repository you end up with X packages having N different minimum version requirements just based on when they've been build and not what is actually compatible.

[ericonr]

Perhaps we could add some sanity check when building a package that a shlib specified in common/shlibs actually exists in that package? Are there any cases where that wouldn't happen?

[Chocimier]

It records the minimum version that provides the SONAME, which makes it easier to downgrade and partially update things.

Shlib-requires and shlib-provides could be enough, but yes, it is easier this way. Thanks.

[ericonr]

This has been fixed.