Downgrading binary packages with pkg on FreeBSD

I had recently upgraded my NAS from FreeBSD 13.0 to FreeBSD 13.1. Unfortunately, I found out that the Deluge package was faulting on startup. It turns out that when FreeBSD updated the libtorrent-rasterbar package, it had broken the Python bindings, and thus Deluge. However, the old Deluge and Python binding package were still installed – they just didn’t work anymore due to libtorrent ABI.

While it’d be ideal if this were fixed upstream, I didn’t have the patience for this right now. So, I decided to downgrade the libtorrent-rasterbar package to be compatible with the Python bindings. There were no other dependent packages, so I figured this was safe. Unfortunately, I had to deal with a few curveballs along the way…

The first obstacle was even though I had manually downloaded the package, and specified the file on the command line, this didn’t really work out:

$ sudo pkg install "./libtorrent-rasterbar-1.2.14,1.pkg"
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be DOWNGRADED:
	libtorrent-rasterbar: 1.2.16_2,2 -> 1.2.14,1

Number of packages to be downgraded: 1

Proceed with this action? [y/N]: y
pkg: archive_read_open_filename((null)): Failed to open '(null)'

Turns out this is a FreeBSD bug – and upstream can’t reproduce it. Oh well, we can do pkg remove -f (the -f is important so it won’t remove the Python bindings and Deluge that depend on it, since we’ll quickly reinstall the package. Then we can try it again…. right?

$ sudo pkg -d install -fU "./libtorrent-rasterbar-1.2.14,1.pkg"
DBG(1)[31237]> pkg initialized
DBG(1)[31237]> want to get an advisory lock on a database
DBG(1)[31237]> Jobs> Adding file: ./libtorrent-rasterbar-1.2.14,1.pkg
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	libtorrent-rasterbar: 1.2.16_2,2

Number of packages to be installed: 1

The process will require 11 MiB more space.
3 MiB to be downloaded.

Even though I specified -U so it won’t check the repo for updates, it still wants to install the latest version. I had ran pkg clean -a, so we don’t have the cached packages either. In fact, it’ll happily and blithely just download the latest version. Clearly, it must be caching the repo metadata somewhere. After checking with truss, I found the repo metadata cache (it’s an SQLite database) in /var/db/pkg. So, we do a little trolling, and temporarily remove that cache. When combined with -U, it should prevent it from checking the repo for a newer version.

[calvin@illmatic ~]$ sudo mv /var/db/pkg/repo-FreeBSD.sqlite /var/db/pkg/repo-FreeBSD.sqlite.dont
[calvin@illmatic ~]$ sudo pkg -d install -U "./libtorrent-rasterbar-1.2.14,1.pkg"
DBG(1)[31307]> pkg initialized
pkg: Repository FreeBSD cannot be opened. 'pkg update' required
DBG(1)[31307]> want to get an advisory lock on a database
DBG(1)[31307]> Jobs> Adding file: ./libtorrent-rasterbar-1.2.14,1.pkg
DBG(1)[31307]> solver: for package: py38-libtorrent-rasterbar cannot find provide for requirement: libtorrent-rasterbar.so.10
Checking integrity...DBG(1)[31307]> check integrity for 1 items added
 done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	libtorrent-rasterbar: 1.2.14,1

Number of packages to be installed: 1

The process will require 11 MiB more space.

Proceed with this action? [y/N]: y
DBG(1)[31307]> want to upgrade advisory to exclusive lock
[1/1] Installing libtorrent-rasterbar-1.2.14,1...
Extracting libtorrent-rasterbar-1.2.14,1: 100%
DBG(1)[31307]> release an exclusive lock on a database
DBG(1)[31307]> release an advisory lock on a database
[calvin@illmatic ~]$ sudo mv /var/db/pkg/repo-FreeBSD.sqlite.dont /var/db/pkg/repo-FreeBSD.sqlite
[calvin@illmatic ~]$ sudo service deluged restart
deluged not running? (check /var/run/deluged/pid).
Starting deluged.

Yay! Deluge seems to work again, and after restoring the metadata cache file, pkg will work as it usually does. I’ll have to be careful about updates (unless I can pin?) until upstream ports fixes the issue with the Python bindings.

4 thoughts on “Downgrading binary packages with pkg on FreeBSD

  1. Albert Camus September 4, 2022 / 7:52 pm

    Use ‘pkg add’ for this situation

    • cb September 5, 2022 / 2:11 am

      This works well, thanks! Unfortunately, people seem to imply pkg add is deprecated in favour of pkg install, even for local packages, so it’s not clear to use that.

Leave a Reply

Your email address will not be published. Required fields are marked *