Package Details: libndi-bin 4.5.1-6

Git Clone URL: https://aur.archlinux.org/libndi-bin.git (read-only, click to copy)
Package Base: libndi-bin
Description: Custom build of ndi-sdk from obs-ndi
Upstream URL: https://github.com/Palakis/obs-ndi
Keywords: libndi obs-ndi
Licenses: LGPL2.0
Conflicts: libndi-git, ndi-sdk
Provides: libndi
Submitter: ShayBox
Maintainer: ShayBox
Last Packager: ShayBox
Votes: 4
Popularity: 0.22
First Submitted: 2020-04-16 23:31
Last Updated: 2020-04-29 06:09

Dependencies (0)

Required by (3)

Sources (1)

Latest Comments

ShayBox commented on 2020-07-25 00:17

:+1: In all reality libndi(obs-ndi) and libndi(newtek) are the same but I made it available in case a newtek update breaks obs-ndi or obs-ndi decides to modify libndi in their fork, I would recommend ndi-sdk as it will almost certainly be more up to date, but if you experience a problem try obs-ndi's libndi

celilo commented on 2020-05-07 22:42

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.

celilo commented on 2020-05-07 22:34

"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

ShayBox commented on 2020-05-07 03:15

@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.

celilo commented on 2020-04-19 01:18

Also, thank you for the build of the plugin.

celilo commented on 2020-04-19 01:17

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.

emileet commented on 2020-04-17 01:22

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

ShayBox commented on 2020-01-13 14:37

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.

Freso commented on 2020-01-13 14:29

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

xkero commented on 2018-06-10 02:23

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/