But this still leaves open a question, at least in my mind: Why did my install (of mpd) not fail with an unsatisfied dependency on the staging version of pipewire? I have neither the testing nor the staging repos enabled in my pacman.conf, so I would have thought that the soname mismatch would catch this, hence pacman would have failed my mpd install attempt due to an unsatisfiable dependency.
Is this reasoning wrong? If so, can you (or anyone) provide a quick explanation of what proper user expectation should be in a case like this (i.e. a required dynamic symbol is absent from a library in the {core,extra,community} repos)? Is it a packaging boo-boo, or just wrong user expectation on my part?
]]>I can only find two packages on my local system with underscores in the version number (dialog and libedit) which both have an underscore next to a date field. I think it's a typo, but the impact should be minimal I reckon.
]]>I found a later version of pipewire (pipewire-1_0.3.40-1.2-pentium4) in the staging repo, which does have that symbol defined, and seems to solve the problem.
Can anyone reproduce this? Steps to reproduce:
1. install mpd-0.23.5-1.0-pentium4 on a system which has libs associated with
pipewire-1:0.3.34-1.0 but not pipewire-1_0.3.40-1.2.
2. Attempt to run mpd from commandline.
What I see is a runtime symbol lookup failure on PW_LOG_TOPIC_DEFAULT.
Then, after updating pipewire to the later version mentioned above (1_0.3.40-1.2), mpd executes successfully.
Side issue/observation: There's a small, possibly unintentional, syntactic difference between the naming of the packagefiles of the two versions of pipewire mentioned above: 1:0.3.34-1.0 vs. 1_0.3.40-1.2 (colon vs. underscore after the leading "1"). Not sure if this is intentional and/or problematic in any way, just mentioning it for completeness sake in case it may have been a typo.
]]>