OK, seems the package is not what I was expecting.
The package seems to just install a copy of Nextcloud into /var/www/nextcloud/ owned by www-data. I don’t see any benefit of a package like that compared to just downloading the software from nextcloud.com.
I was expecting something similar to the WordPress package found in Debian. e.g. Nextcloud code is installed in /usr/share/nextcloud/ owned by root. Config files found in /etc/nextcloud/ and then the datadirectory in a user-specified location (like /var/www/nextcloud/). This separates the data, which the server should be able to edit from the core code which shouldn’t be editable by the server, and should only change when packages are updated.
I’ve manually setup an install along those lines, so if you’re interested in creating a package along those lines, I can explain how to create the setup.
That is right and probably the reason, why Nextcloud itself didn’t want to get involved into packaging.
Because such an integration is much more specific for each distribution where it needs a deeper knowledge of it and though can be better maintained by the distribution’s community (or someone who is active in both communities).
Neither will I. You just need to add a new apps_path to the config, so it will load the core apps from /usr/share/nextcloud/apps/ and install new apps to /var/www/nextcloud/apps/.
If you’ve installed Nextcloud through the package manager, then you expect to upgrade through the package manager. The upgrader in the Nextcloud UI should really be disabled (much the same as in WordPress).
If you want to upgrade through the Nextcloud UI, then you should install Nextcloud through the normal process (again, I can’t see why someone would want to use a Debian package if it’s not going to do anything different from downloading the code from the website).
Sure, the most difficult bit, is that it would ideally be read-only, which Nextcloud complains about. I’ve tweaked the Nextcloud code base to run with a read-only config, and am currently testing it out. Everything seems OK at the moment, I’ll just have to wait and see how well it handles an upgrade.
Like I said, I’m happy to work with you setting something up, if you’re interested. But, I’m not familiar with Debian packaging at all. I tried to package a one file script some time ago, and it took me all day to get it working.
While I greatly appreciate your efforts of maintaining this repository, there are 2-3 things that repeatedly turned out to be a pain in the butt and that might be possibly improved:
Your package overrides the .htaccess file instead of using the debian default to ask whether to replace it by the maintainer’s file or not (at least in my experience), making me loose pretty URLs on each upgrade.
You always only have the latest version in the repo. So if I missed the upgrade from 13 to 14, then I’m stuck and have to first manually upgrade to 14 (using the tarball) before I can use your package to upgrade to 15. Why not keep at least the latest minor releases of each major release?
Your package doesn’t check what the current version is. IMHO, before upgrading, it should check whether the current version if more than a major version behind and refuse to run the upgrade, rather replace the files and then bail out on occ upgrade.
Good idea to make packages for all supported Nextcloud versions, in this case 15.0.2, 14.06 and 13.0.10.
I not sure You think about generate packages:
nextcloud13-server
nextcloud14-server
nextcloud15-server ==> nextcloud-server
But Nextcloud high recommended the lastes release to keep on server, I don’t see point of keep Nextcloud 13 or 14 server in production.
If use package from this repository, upgrade will be done without problem, only if You have web install I recommended to make backup of /var/www/nextcloud and database then update to latest version and on finish install nextcloud-server from repository and in future use only upgrade with apt.
It seems that @ijurisic’s packages haven’t been updated for a while (no NC 16 yet, do Debian 10 yet), and yet some current NC apps require PHP7.1 which mean they don’t work anymore on current installs.
Does anyone here have a solution for that ? How do you people manage your Debian stable installs ?
Oooh, that’s wonderful !
How will the update from a stretch+NC15 install go ? Will I have to just do s/stretch/buster/g /etc/apt/sources.list then the apt dist-upgrade dance ?
Please be aware there may be some caveats, certainly the change of ethernet interface names and how to manually migrate your database to e.g., mariadb-server-10.3, from an older version after the dist-upgrade has happened. The below may also suite you, I hope.
Ref the a.m. documentation including but not limited to the below in particular:
Blimey. What would be your requirement for “easy”?
Please be aware the most “easy” way may be to get the professional Nextcloud support at the price most appropriate to your sites and demand.
Please note for a lasting time the consecutive updates and several migration to quite a bunch of machines (iron and/or VM) from Debian 8 and Debian 9 to the recent Debian 10 gave one no true hassle ever, if I may.
Just ask a friend of yours who is truly capable of managing such effort. You could blame this person for any mishaps and you should pay the beer to support the sociability, hopefully.
Nevertheless, AFAIK the kind experts from Nextcloud and the able helpers of the community are providing some online documentation worth reading such as:
BTW a little ack to my comment (i.e. click on the heart icon ) would show you are satisfied. This could be a kind gesture and would motive me in helping others in this forum…