Arch Linux User Repository

Btw, I edited the ndi-sdk package build myself so that I could install both ndi-sdk and obs-ndi without conflict. I'm not waiting or expecting any action from you. Just trying to improve the AUR.

"in theory you could use ndi-sdk, but they don't provide libndi in their pkgbuild like they're supposed to" As I said, I understand that they don't include the "provides=('libndi')" in their pkgbuild. That could easily be remedied by communication.

Your concern about versioning is valid. However, the ndi-sdk maintainer could simply add a versioned provides, "provides=('libndi=4.5.1')", and you could add a versioned dependency, depends=('libndi<=4.5.1'), or whatever is appropriate.

This solves the package management issue as designed. I get that it's easier to build something independent than to work with another package manager, but your same argument could be made for most dependencies. Can you imagine if every package manager followed your path. Good luck with any package update!

I'm betting that the ndi-sdk maintainer would be happy to cooperate to achieve the best solution. I've never found a package maintainer that wouldn't. Probably could be resolved properly in less time than our conversation:)

Thanks

@celilo, There's currently no difference between ndi-sdk and obs-ndi's libndi, but they still provide it so I will continue to package it in case of any differences, in theory you could use ndi-sdk, but they don't provide libndi in their pkgbuild like they're supposed to, and this package conflicts with it because both packages provide libndi.so, which causes a filesystem conflict.
In addition, if ndi-sdk updates and obs-ndi doesn't, the lib update could break obs-ndi, while libndi provided by obs-ndi is version tagged.

Also, thank you for the build of the plugin.

What is so special about this build of libndi? It looks like there was a previous bug that has been fixed. "With NDI 4.5 installed on the system, obs-ndi 4.7.1 would crash. This is now fixed with the addition of NDI 4.5 support." The current libndi from ndi-sdk is currently identical and there appears to be no additional reason to maintain a separate libndi in this package.

I would suggest that you install ndi-sdk as a dependency rather than the custom libndi. This is the Arch way. If a conflict occurs in the future, you could add the custom libndi back into your build.

Adding ndi-sdk as a manual conflict breaks the ability to concurrently install ndi-sdk. I'm asked to remove ndi-sdk upon installation of the OBS plugin. You provided your own answer in your comment.

The proper resolution would be to communicate with the ndi-sdk maintainer and ask Daniel to add the provides. This would give the user the opportunity to select which library to keep upon installation. Much cleaner. Of course, removal of the custom build seems best at this time since there is no conflict.

hiya, i get this annoying notification

ldconfig: /usr/lib/libndi.so.4 is not a symbolic link

if you could kindly add this to the PKGBUILD so that libndi.so.4 gets symbolically linked to libndi.so.4.5.1, that'd be swell <3

rm "${pkgdir}"/usr/lib/libndi.so.4

Thank you, I added ndi-sdk as a manual conflict since they don't have libndi in their provides and changed the description to be more telling to what this is.

This package installs to the same file locations as ndi-sdk so this should be reflected in the package data.

The license for this package is incorrect (it's unfortunately not free software), the only files it installs are proprietary library files from NewTek's NDI SDK: https://www.newtek.com/ndi/sdk/