I’ve followed the packaging situation with Seafile for a while, and that was always my mayor concern for deploying/using Seafile in a production environment. In the past new features always seemed to take preference over consolidating the code-base by Seafile Ltd. But Seafile GmbH wasn’t much better in my opinion, I was very disappointed when the installer scripts were written, because I thought this is effort that should have gone into planning and moving to a packaged code structure, instead of writing scripts to install Seafile on one particular platform, in one particular way. Which is not good for anybody whose infrastructure is setup differently, or who uses different technologies. As a sysadmin, I would have never used those scripts, even if I could have, in my environment. Might have had some value for home-users, but not much else IMHO. Whereas, having official, standard OS packages would have helped everybody, regardless of whether they use Docker, lxc, Puppet, ansible etc for deployment.
That being said, since then there have been a few improvements in that space. Most importantly, the config and application files are now somewhat properly separated. So, I think doing packages now should be easier than it was in the past.
I, personally, wouldn’t be too worried about Seafile not being in the official Debian (or whatever else distribution) repositories, as long as there is an ‘official’ (Seafile) repository. Those packages would always be quite out of date anyway, considering how often there is a new server release. If it’s in there, fine, but I’d probably use the Seafile channel to install anyway. Having a testing/stable version wouldn’t hurt though, for the more conservative use-cases where new features are way less important than a working service.
Also, I agree that Seafile is not a straight-forward app to package, but it’s not the most complicated either.
I guess the main problem is that it can be deployed in a few different ways. For example using SQLite or Mysql or Mariadb as a db backend (and potentially PostgreSQL). Also, there are a few different configurations for webservers (none, Apache, Nginx, …).
Having to sort all this out is cumbersome, but in my experience at least, it also helps you understand your codebase and it’s problems: where your abstractions don’t really work, where you have assumptions that you shouldn’t have, that sort of thing. Either way, I do think native packages would greatly benefit the adoption of Seafile, much better than any new features would.
So, if I was the person responsible, this is a quick outline what I would do:
- look for a few other applications that are similar to Seafile, see how they did the packaging/deployment
- decide on which packages I want to create (I’d recommend deb as well as rpm, ideally debs would work for both the latest Debian and Ubuntu versions and rpms for RedHat/CentOS/Fedora – whether that is possible is to be determined)
- if you think you can only support one package format reasonably, that is fine too. Just make sure to document the work you do properly, and put the scripts you use somewhere prominent. That way it’s much more likely that the community will pick up packaging for other targets
- decide how many packages you want to create (common, client, ccnet, seafile, seahub, server-community, server-pro, …), make them independent/dependent on each other as much as possible (server-pro depends on server-community, for example, if appropriate) – this might require re-factoring of some components, but, as I and others already said, this exercise it usually worth it in the long term
- put config files in the appropriate directories (under /etc)
- make a list of dependencies that can be sourced from the host distro, and ones that need to be included in the packages
- check out ‘fpm’ ( https://github.com/jordansissel/fpm ) if you haven’t already, and if you don’t have experience in packaging applications. I’ve made good experiences with it – even if you just use it for prototyping and to get your head around the whole thing
- decide on a ‘most simple’ install scenario (probably community version, using sqlite and no external webserver), use that as a starting point – if somebody installs the package, they get a running seafile server, even if it uses an ‘ugly’ port and ‘only’ sqlite
- other setup scenarios can be done (initally at least) by the user manually, but should be documented properly (but that work is mostly done already – I think the manual is quite good in that regard) – this is something that is acceptable in my opinion, I have to do that for a lot of other packages as well (e.g. put Nginx in front of a web-app). In the future, other ‘default’ scenarios could be included, e.g. let the user choose on setup whether to use mysql or sqlite and install the right dependency if a local mysql server is used. Remains to be seen whether that is feasable or not though, I wouldn’t worry about it too much at first
- include example config files for as many scenarios as possible in the packages (in /usr/share/doc/seafile or so)
- now, the main problem is updating the server, here is where you need to make sure you take into account custom setups:
- if in doubt, the installer should not go ahead with an update
- create and document scenarios supported by the packages (mysql, sqlite, …)
- make sure you have test environments and a set of automated tests ready for every scenario you ‘officially’ support
- once those basic packages work, you should have enough experience and a good overview what is involved in packaging the ‘pro’ packages
I’m sure I forgot a lot of things, and some of what I’ve written is not possible for some reason or other. Just consider it an opinion of a user who is quite fond of Seafile (the application), and who wants to see Seafile Ltd to succeed.
Good luck, either way!