So, a lot of people do ask for packages. And I understand the advantage, I’d appreciate them myself, too.
But it is hard to do packaging right and we’ve had trouble with that in the past and we prefer distributions to pick this up for now.
Perhaps there is a solution: let’s be less ambitious.
We provide only the simplest, bare-bones packages: just a tarball in a RPM or Deb with version number. No complicated upgrade fu, no dependencies, nothing like that. So a single package works on all distributions and versions.
It will work for many people (including myself) tough we have to warn people they have to handle dependencies by hand.
What do you think? And is anybody willing and able to help with this?
Edit after some discussion:
And note that there are still enough problems: each distro still needs the files to be owned by another apache user (www-data, wwwrun, apache, …) or in another folder (/srv/htdocs/nextcloud? /var/srv/www?) and we probably should try to ship an apache config and a php.ini perhaps, too, bringing in, of course, more trouble. See? Even simple isn’t… simple.
I was actually contemplating helping you guys package for Debian (which is what I run) but on second thought, dealing with all the versions of web servers and all the versions of PHP and also databases - not a fan of. Nextcloud is definitely something that’s non-trivial to package, because of all its dependencies and the involved setup process.
A barebones Deb seems like a good solution on the surface, but what does that really get you other than auto-pulling a tarball down from a repo? I think it’s either full package or bust to be honest.
The good thing about packet managers is that they solve all dependencies, so that a simple apt-get install nextcloud will do all work (install database, install all php modules, …). There are very little benefits of a bare-bone package compared to the zip-file.
The first time installation is the only point, where distribution packages pay off. Updates and upgrades should be as simple with the new updater app. First time installation is however not very easy and most people rely on 3rd-party guide which are often outdated. I found a “hidden” guide in the documentation (https://docs.nextcloud.org/server/9/admin_manual/installation/source_installation.html#example-installation-on-ubuntu-14-04-lts-server). Why “hidden”? Get yourself in the situation of a first-time Nextcloud user:
you get Nextcloud here: Download and install Nextcloud
The linked documentation page is: https://docs.nextcloud.org/server/9/admin_manual/installation/
This landing page is everything but clear and well-structured (for a new user). Even for experienced Linux users it is not clear where to start (manual installation should be at the top, directly linking guides for Ubuntu and CentOS. Installation and managing of apps start to be interesting once you have a running setup of Nextcloud, it’s way to prominent here). And manual installation implies that there is an automatic one as well…
It may be useful to have a look at how Dolibarr handles this (I write only as a Dolibarr user, installed on locahost).
The DoliDeb package handles the basic dependencies and integration with [apache2|lightppd], php and MySQL – in other words, if you want a package, you have to use it within clearly defined limits. Don’t use the package and then complain that there’s no nginx support, or that it doesn’t recognise your MariaDB version.
After upgrade, an install script starts on first access, which determines what must be done to get from the old version (not necessarily the previously most recent version) to the new version. In my experience, both the initial installation and subsequent upgrades were reliable and simple to do.
An official repository which depends for example on a LAMP stack would be no too bad for standard installations. If somebody wants to go with a different webserver or database system then they could use the *.tar.gz package and do a manual configuration.
Maybe configuration management software like Chef Solo, Ansible etc. could be useful to configure the whole system? Gitlab does it that way for example in their default omnibus package. If somebody needs something more special they can do a manual installation.
Hi all, my name is Giacomo and I’m one of the main developers of NethServer.
We are more than happy to help on maintaining and testing Nextcloud packages for CentOS 7 (and eventually CentOS 6).
We are leaving ownCloud behind and embracing Nextcloud for the latest release of our distro which is based on CentOS 7.
In our experience, packages from the vendor should include:
the software itself, of course
all strictly required dependencies (like php modules)
eventually a configuration file for a widely used http server (like Apache or Nginx)
no upgrade/install scripts
Any distribution should be free to decide how the software must be configured (MariaDB vs SQLlite, internal vs external users, etc).
If the distro doesn’t configure the software, the admin should be able to do it following Nextcloud documentation.
In our distro, which is targeted to non expert Linux administrators, we automatically configure all the following:
Apache as web server
MariaDB as database
External users on OpenLDAP or Samba 4 (depending on what is installed)
DUDE, awesome. I’d love that, more than that, we’d link to it from our home page and fully credit you and the Nethserver crowd for providing this. AWESOME.
Perhaps this also helps @FredFS456 to feel a tad more confident about doing/maintaining Deb packages: you can start from there? And there might be other package specs lying around that can be improved/used as a start.
Very good! Give me a couple of days: I want to carefully read all guidelines and try to build a plain rpm for CentOS 7. Then I will post here my findings to get feedback from all interested users
At the end, I would like to write down a simple howto about testing the whole NextCloud installation on both CentOS and NethServer.
I’ve just created a first implementation of a very basic Nextcloud rpm package.
Following Jos idea, the RPM is much much simpler then any Owncloud packages from official repo or EPEL.
Distro packages are okay if a) they provide the right dependencies and b) ensure a smooth upgrade path going forward. Seeing that I use nginx and Mariadb a) will not work for me so I have to do a custom install anyway and seeing that I absolutely want some kind of semi-sane upgrade path I install from a git branch direct from Github and do a weekly “git pull” on all installs. If upstream provided some kind of official “live” branch that removed all the development clutter then a direct git install would be even better. Then if there were some “trusted” bash scripts in an official github repo to handle installs, dependencies and upgrades via “wget script|bash” we could have a very simple but effective Nextcloud management system that could bypass all of the distro packaging limitations. Eventually these mythical bash management scripts could be ported to a golang app so that “go get github.com/nextcloud/nc” could provide all the dynamic management of Nextcloud installations under a huge range of conditions in a single app that would run on just about every OS available (like LAMP) all based on this “live” Github branch.
It is hard to entirely bypass distributions as they tend to put their config files in different places, though, you still end up with much custom “oh Debian puts em here and RH there and SUSE there” cruft
I prefer distro packagers to do the distro specific parts and we provide something that just works but bypasses the distro’s. For that, a VM or docker image is easier than a scripted install, I think.
I agree, this is the purpose of simple deb/rpm packages.
I think this approach could work also in your scenario.
After the package install, you must configure Nextcloud and MariaDb to work together.
In case of a package upgrade, you don’t have to change anything: the configuration isn’t lost and you need only to open the Nextcloud interface and click the upgrade button.
Of course, you can automate this part, but IMHO this should not be the goal of simple generic distro packages.
Hi again,
we finally have our Nextcloud package for NethServer up and running:
it’s based on the “vanilla” rpm I posted before and it works quite well for our purpose.
But I wouldn’t like to waste the opportunity to work together: we should improve and maintain a simple package like this. @jospoortvliet how can we push forward this effort?
Give me a couple of days: I want to carefully read all guidelines and try to build a plain rpm for CentOS 7. Then I will post here my findings to get feedback from all interested users 
