Arch Linux User Repository

@ghoti It's not a compatibility problem. This app works fine but it must be rebuilt using sources that match the ICU version you are running. If you installed manually rebuild and it will work fine. If you used yay, try yay --rebuild -S nasc.

the ICU UC libraries seem to be broken, and 67 and 68 really do appear to be incompatible with eachother.

Not sure what could be done to fix this.

icu package got updated, but this build still points at libicuuc.so.67. Therefore, it fails to start. It should point to libicuuc.so.68 while loading shared libraries.

Renaming the binary does not achieve any practical goal

Sure it does. It would bean I can launch it from the CLI or my desktop UI's launcher by typing in something sensible and expected. Reverse domain names as /usr/bin entries is nonsense.

Even the upstream started out doing something sensible and only switched to the RDNN scheme because their primary distribution channel is Elementary OS's AppCenter and it uses RDNN for all desktop apps. Their entire user model is heavily mouse/menu driven though so they don't care about the things Arch Linux users are likely to care about. I want to be able to launch an app under the sensible name that the pkgname and even upstream project repository are sensible enough to use: nasc.

I don't see why Arch Packaging should be held to doing silly things like this just because some other OS packaging scheme calls for them.

Thanks @aperez, fair point. It's a fairly unfortunate binary name to launch, but I suppose a user can symlink if they prefer the actual app name instead of the namespaced one.

@Alexmaras: In general the way things are done when packaging software for Arch is avoiding modifications of the upstream software if possible. Renaming the binary does not achieve any practical goal, and would introduce differences with upstream, so I would rather not do that.

Might be worth updating the PKGBUILD package() function to rename the binary from com.github.parnold-x.nasc to just nasc