And to note: Please report issues then when you see them throughout the issue-tracker. When you have found the reasoning through personal tryouts this is even more helpful instead doing that throughout Github-issues and we see that just because we read carefully enough. I will close this thread now as all is said and done.

Now under a new topic created. If there are further questions: Feel welcome.

Yeah, I noticed that was why the NooDS emulator didn't have sound. a few days ago...

Was not happy... but yeah, I understand somewhat why...

So... desmume isn't needed after all.

However, this is just a thought, but why not have a second version of said package called portaudio-sndio?

They would be packages that conflict, aka you can only have one... that would be how it could work.

Btw, I actually have the old portaudio with sndio support, so just ask and I can send it to you.

Sound can work this way with NooDS this way too.

Second therefore the elementary problem being removed as this is and was the sndio-patch: https://git.hyperbola.info:50100/packag … 05a7406334
The reasoning for removal: We have NOT only sndio even if people demand to be it that way. Under GNU/Linux we have also ALSA running and for that reasoning we need to keep compatibility with others like espeak, which showed issues with usage at the point before release of version 0.4. We had therefore the choice: Removal of all packages with problems in relation to portaudio or try fixing it on other ways. We took the decision for everyone to see. If somebody is using sndio ONLY on the system, then there will be for sure problems as there is no choice of both, only one. To keep all packages, to keep them running we made this choice: It was a hard one at the point, taken days for analysis and fixing also ALSA therefore. I hope this helps a bit more to bring transparency for questions!

We will for sure try to bring sndio-support therefore back at a point when possible. But we had first to deactivate sndio at the point back before we came to the conclusion it was a different base. But we need to make sure at every point also in the analysis that packages and depending applications work like they should.

We just cannot upgrade every package on wish or on point: This could make the whole system unstable and we will never risk that. Fixing instabilities can be very complicated as it can took days or even weeks with high workload every day and Hyperbola is driven by people in the free time. So there won't be much more packages added and also only upgrades when we can make sure they are functional and do not risk stability.

Hyperbola is also technical emancipation oriented. So using and upgrading on your own is for sure wanted, if you wish for that and it should be always possible. But I won't debate our stance here in this thread. If you have further questions, technical or more: Please create a new thread therefore. Thanks! Also to underline: We can create a new thread for updating selected packages and show how to do that, but this is for sure therefore a part for the community: Learn how to do and share. We can look over together as it can't be our task alone for about over 2000 packages (32bit and 64bit). We had discussions even about to drop what we can to preserve what is there. When we can guarantee a safe update-path, we will use it. But not for our build-infrastructure at this point and not for elementary libraries also with many dependencies. The reasoning is always the same: When we need to do that with a complete new release and version, there is testing needed. No further testing means also more time needed as we need to do all with a small amount of helping hands. So I won't ask for any kind of agreement, but this understanding of our reasoning for doing that to preserve a stable system. Not doing that for getting someone mad or angry. But when something is malfunctional, we do what we need to do - for example for portaudio as there were errors within ALSA at a time to be fixed if somebody wonders why the sndio-patch got removed. As said: Not doing that to get people angry, but we do it for preserve a functional system with functional applications in the user-space.

As the version of desmume is on pair with Debian, we won't upgrade this as long Debian is doing that also. I can write down the ruleset a bit more clear:

1. Trying to be on pair with Debian with version of an added package - with having in mind back also that this is meant foremost for libraries and applications around the user-part, not for building as we won't touch that in times of developing our kernel and userland for HyperbolaBSD.
2. When there is no Debian-version or the version has problems, we can think about updating.

But when the package is working - seems so for desmume: We won't touch it for the moment. Okay, desmume is a for sure not critical and it is an end-user application. Nevertheless there is also one rule to follow: Never touch a running system!
Updates for security-problems, if there are malfunctions or something, but not being something like Arch GNU/Linux rolling on selected packages. What is possible: Creating a thread later on and trying to do a PKGBUILD together so it is part for learning how to check and setup. Because using "make install" should be better used only in your HOME-directory instead in the root-filesystem.

This is one time, I cannot agree with you... at least as far as "debian has it so we shouldn't."  That being said, your reasoning for HyperbolaBSD is completely solid.   Point being,  your other reasoning, could scare away people who actually, want minimalism like Hyperbola and the values Hyperbola has as a whole... keep this in mind, if possible.

Edit: typo

1. Trying to be on pair with Debian with version of an added package - with having in mind back also that this is meant foremost for libraries and applications around the user-part, not for building as we won't touch that in times of developing our kernel and userland for HyperbolaBSD.
2. When there is no Debian-version or the version has problems, we can think about updating.

But when the package is working - seems so for desmume: We won't touch it for the moment. Okay, desmume is a for sure not critical and it is an end-user application. Nevertheless there is also one rule to follow: Never touch a running system!
Updates for security-problems, if there are malfunctions or something, but not being something like Arch GNU/Linux rolling on selected packages. What is possible: Creating a thread later on and trying to do a PKGBUILD together so it is part for learning how to check and setup. Because using "make install" should be better used only in your HOME-directory instead in the root-filesystem.