Re: php-nextcloud 33.0.6!

[Greg Troxel <gdt%lexort.com@localhost>]

Andries Annema <an3s.annema%gmail.com@localhost> writes:

> Not sure if useful or if this applies to NetBSD as well, but let me
> post my two cents anyway.

I think it is useful and thanks for posting.

> 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?


I do find that updating by clicking in the web ui is flaky and I end up
doing it with occ.  That I think avoids all the resource limits that
php_fpm (reasonably) imposes.



I am on the verge of updating the package to 34.
I avoid that when it's newly released, but it seems baked enough.