pkg management - handling non-repo dependencies

[mihak]

I am tidying-up the speedtest plugin that I cobbled together in the last few weeks (https://github.com/mihakralj/opnsense-speedtest)


During the development, I included the copy of binary for speedtest directly in the .txz - but now it is time to remove it from the package and declare an external dependency. The problem is that Ookla's speedtest is not part of any repo (that I know), so their installation guideline is asking for a direct pkg add installation command.


Having a PLUGIN_DEPENDS statement in the Makefile will stop the installation of the plugin if speedtest is not installed prior, but it would prefer a more streamlined method where some +PRE_INSTALL (if it exists) would run the required pkg add command for a 3rd-party package that is not found in any of linked repos.

[mimugmail]

Why don't you use +PRE_INSTALL? Just don't forget about +POST_DEINSTALL.
If you add your copyrights to the plugin I can add it to the repo, also the binary itself.
Maybe also think about moving Speedtest to Report section instead of Dashboard.

[mihak]

like this?

if [ ! -f /usr/local/bin/speedtest ];
  then sudo pkg add "https://bintray.com/ookla/download/download_file?file_path=ookla-speedtest-1.0.0-freebsd>
fi
pkg info libidn2 > nul
if [ $? != 0 ]; then sudo pkg install -y libidn2; fi

[mihak]

Ummm - this chaining of pkg statements is not working. When running the script above either as a +PRE_INSTALL or +POST_INSTALL, I get:


pkg: Cannot get an exclusive lock on a database, it is locked by another process


Any other ideas? :-)

[mimugmail]

Maybe we were crosstalking, I wasn't talking about adding it to the official repo, I have no write access there and adding a binary inside the pkg is also prohibited. But for building a trustworthy plugin (sorry, no offense!) I need the source ad my repo (also for adding the binary).

Is this ok for you?

[franco]

Everything that needs compile or extended dependencies needs to go to FreeBSD ports tree or our extended tree worst case. We would like to be able to vet the sources, check for updates and adjust when issues arise. This is also important because the build produces compatible binaries and getting something from somewhere is going to break eventually.

From the plugin the install afterwards is as easy as adding

PLUGIN_DEPENDS= my-dependency-package-name


Cheers,
Franco

[Patrick M. Hausen]

@mihak Can't you use py37-speedtest-cli?