Like I said, rabbit holes, impossible to know on a per distro basis, which is why I always ignore package data, and only support actual files and programs and process names etc. alsa-lib is just a package name, and thus, from inxi’s perspective, is not a thing, as I said.
libraries are in general also not “a thing” for inxi, because they usually are just files somewhere, and usually not in $PATH, and usually don’t have --version info.
Good info on the pipewire-alsa, I’ll update pinxi for that, and add pipewire-jack.
Note however, pipewire in all cases is the sound server, as the pipewire doc clearly stated, these are just daemons running on it. I thought the docs were clear and well written, and did their job re explaining the stuff, except for the pipewire-alsa, which was not clearly explained. There was a small weak spot because I was not aware of such pipewire daemons as pulse and jack, the detection to see if pipewire is running just looked for pipewire in the running string, that has been corrected to look for pipewire[d] ending with space or eol.
One small note/comment however: when you say “You should ask him about PipeWire packages” what you actually meant to type was “I should do this to help out since research and communication is immensely time consuming [at least 90+% of inxi dev time, maybe closer to 95-98%] and not expect the inxi dev to do everything himself, particularly when it comes to stuff he doesn’t care about or use himself, and besides, I might learn something interesting I didn’t know before”.
Basically the area of software running on system was actually something that I was warned about trying to support in inxi, because it’s such a huge rabbit hole, which will always churn, but as long as it makes sense, and can be clearly explained, I tend to do it, though support/help for those things, particularly with desktop/window manager/compositor/graphics api stuff has been limited basically to one person other than me who is interested in such things, at least, some of them, but only a narrow slice of the possible set (xorg + trinity/kde).
Do note however, if I hadn’t randomly checked this thread, I would still today have no idea that pipewire-pulse/jack are things that exist as daemons of pipewire, I don’t spend all my waking hours tracking down changes and developments in the software stack of free desktops/servers, I tend to focus such efforts on specific goals and development cycles, which tend to cover huge areas rapidly, but those are intensive efforts which are not something I can do all the time, unless someone wants to pay me to do that. In other words, I can’t do it all the time.
Recent such things, as noted above, were the massive CPU refactor, which locked down cpu support for the coming years because it’s so robust and dynamic, and dumps almost all the hardcoded fixes and methods, except for legacy hardware/os/kernels, with one exception, the manually updated cpu matching tables which is where the advanced cpu data comes from, like arch:, gen:, year:, and so on. Happily modern cpu development has slowed to a crawl with increasingly near impossible process node shrinking, so these updates aren’t required as much as in the old days. But the CPU stuff is over 99% research, with no authoritative sources for the data, just a collection of sites that are useful, but none complete.
The other area is the newer gpu advanced data, also manually updated from master lists from some resources online, but in the end, manual to some degree. This is about 95% research re time, give or take.
All these manual matching table items now are split out as standalone tools in pinxi/tools which made maintaining them a whole lot easier long term, so those aren’t as much of a pain as they were last year.
These things all happen when/if I feel like doing them, the cpu stuff I sometimes get some help with but not usually, nobody is interested in volunteering long term research commitment so I end up doing it. One day this will stop being interesting and I’ll stop doing it, but for now, it’s so scripted and automated that the research isn’t that time consuming, and only has to be done every release or two. Same for disk vendors, another huge regex matching table, and some other items.
But software stack stuff, that is just something that has to be added if stuff is added. In this case, I leveraged the existing output syntax used, as noted, for with: xwayland, except that the pipewire daemons, being essentially sub parts of pipewire, have the same version number as pipewire shows, so there was no point in repeating that.
This is now in pinxi 3.25.-6, with pipewire-pulse/pipewire-jack pipewire daemon detections now in place.
This logic also permits the other sound servers to supply such sub daemon data.
Since I’m looking at this now, I may add a few basic tools as maybe -Aa like with -Ia/-ra a report of detected tools, which might be of some utility, though again, the requirement to create another list of detected tools like packages has, but those things don’t change much over time, and the -A feature has always been somewhat barren.
Stuff like pavucontrol, pulsemixer, alsamixer, and so on. That’s pretty easy to do, and would make an actual reason for a new inxi release.
Technically, at least debian packages lists pipewire-alsa and pipewire-jack as plugins, not daemons, only pipewire-pulse is listed as a daemon. As I said a rabbit hole.