pkgin upgrade on OS X trunk results in doa pkgin binary

[rmustacc]

I did a pkgin upgrade today. It opted to update the following packages:

$ sudo pkgin upgrade
calculating dependencies... done.

8 packages to be upgraded:

pkgsrc-gnupg-keys-20160519 pkgin-0.9.4nb4 mpv-0.24.0nb3 gnupg2-2.0.30nb2 sqlite3-3.16.2 pkg_install-20160410nb1 curl-7.53.1 nghttp2-1.20.0

The end result however is that pkgin no longer runs:

$ sudo pkgin in lynx
dyld: Library not loaded: /opt/pkg/lib/libarchive.13.dylib
  Referenced from: /opt/pkg/bin/pkgin
  Reason: Incompatible library version: pkgin requires version 17.0.0 or later, but libarchive.13.dylib provides version 16.0.0

[jperkin]

Sorry, looks like libarchive major got bumped again but we didn't note that in pkgsrc so pkgin will still accept the previous version. I will fix this in pkgsrc so at least future users shouldn't hit the same issue.

As for a workaround, things should be fixed if you run pkg_add -U libarchive to pull in the newer package. It's also worth mentioning that a pkgin full-upgrade would have avoided this issue, and is probably recommended for most upgrade operations. I'm not personally convinced of the need for upgrade, and as a separate fix will see if it's worth just making it behave the same as full-upgrade.

[rmustacc]

Thanks, that fixed it. Unfortunately I didn't really remember that both of the upgrades existed until I was already hosed and it was too late.

[anadrome]

Also got hit by this, but it was an easy enough fix, thanks.

I also would prefer upgrade to behave like full-upgrade by default, and the existing behavior if anything to be housed under some less-default-sounding name like selective-upgrade. Not only because it would result in fewer obscure dependency issues, but also because in the everything-is-exposed-to-the-internet era, a big % of library updates have security-relevant patches, which you probably don't want to skip. I get the rationale of being minimalist in upgrading dependencies—why waste bandwidth upgrading libfoo2.1 to libfoo2.2 if none of your installed software depends on v2.2 features?—but I don't think it's a good default policy anymore.