I have been running a so-called lipkg zone on Illumos/OmniOS for years
with nginx, php and php-nextcloud from pkgsrc. A while ago I bumped
into one php-nextcloud release that was purged from the pkgsrc repo,
which got me stuck, preventing me from upgrading any further.
The general rule in pkgsrc for nextcloud is that we never jump more than
one major version across quarterly branches. There have been older
nextcloud versions like "nextcloud30" at times when there was such a
jump (would have been 29 last branch, 31 now), but 99% we just avoid it.
pkgsrc history is available in CVS, so if you're willing to build your
own packages, you can check out whatever version and build. I did that
when I got behind several years ago.
With binary packages, you'd have to find them and upgrade to them, in
sequence.
Long story short, I removed the php-nextcloud as used from pkgsrc and
installed Nextcloud manually from the official tarball from
https://download.nextcloud.com/server/releases/ - starting with the
version I was stuck at - while keeping al dependent php packages from
pkgsrc.
That way I can:
- update all packages used from pkgsrc the usual way,
- update Nextcloud itself using the built-in update mechanism, one
major version at a time.
It also requires upgrading PHP and the dependent MariaDB database
releases, since the dependencies from Nextcloud evolve over time, but
that is a separate matter.
That's an interesting datapoint that deps from pkgsrc and tarballs from
nextcloud work together.
In the past I have also seen things break when using php-nextcloud
from pkgsrc and updating using the built-in update mechanism once,
which screwed up the pkgsrc update cycle with all sorts of errors. So
don't mix update mechanisms...
As I understand it, by the time nextcloud runs, it can't tell whether
the bits in /usr/pkg/share/nextcloud were just unpacked from upstream,
or unpacked from upstream in a package build and installed via a
package.
Perhaps it was just that you didn't remove the unpacked tarball contents
before installing a package? pkgsrc thinks it owns /usr/pkg ($PREFIX
really), and putting other stuff there needs manual attention.
It is too risky to grab php-nextcloud from pkgsrc IMHO. Grabbing
Nextcloud itself from the official archives while using pkgsrc for all
dependencies works much better.
Do you mean that just because of the 1-version-only update bug in
nextcloud?