I’m the current maintainer of the seafile suite for Archlinux in the AUR and I am here to get some feedback to properly package everything. As a side note, seahub is not yet properly packaged but it will be in a near future.
I’ve read the following thread and the blogpost with some interesting information but I have more questions.
Before version 6.0.1 one PKGBUILD pulls from seafile Github repository and create a
seafile-server package with all stuff related to the administration and a
seafile-shared package with all libraries and daemons.
It was easy to get
seafile-client from the seafile-client Github repository working by only depending on
But now, with the apparition of the seafile-server repository it’s more complicated because :
seafile-server repository does not have the
seaf-daemon binary and cannot be used for the client,
seafile repository seems to be not updated (still at version 6.0.0),
if both seafile-server and seafile are installed at the same time, there are conflicting files and different versions of the library…,
seafile-client is still to version 5.1.4 and the README links to the seafile repository.
Could you provide me some information about all those repositories, especially how they will evolve and how to split everything correctly?
Many thanks by advance,
The purposes of each source repositories are described here: seafile/README.markdown at master · haiwen/seafile · GitHub
The “seafile” project is only used for sync client daemon in the future. The seafile core is “seafile-server”. The old server code in the seafile project will not be maintained any more. So pointing to the “seafile” project is correct in the seafile-client project. The seafile-client project is the GUI of the sync client.
This is currently an issue. We’ll clean up the overlapping header files and libraries in these two repositories.
Thanks for the quick reply and the precisions about the repositories.
I will delay the update until the seafile repository get cleaned of all the server components. Should I open an issue on Github for that ? Besides, do you have any roadmap for this cleaning ?
Yes opening a Github issue to keep track of this is a good idea. You can open it in the Seafile project.
Since we’re going to have holidays for 1-2 weeks, this would be fixed in about a month.
Thanks again for the quick reply, I opened the issue on Github https://github.com/haiwen/seafile/issues/1766
A small ping on this issue, as it seems that there is no change in the two repositories and the packaging is still complex.
Besides, could you explain me the difference between the ccnet and ccnet-server repositories?
Sorry for the delay. As some higher priority tasks came in, we have no time to work on this in the last month. I’ll take some time to fix it if I can next week.
Thanks for the news, I will wait for the new version without the conflicting files to update the AUR packages.
This issue is mostly resolved now. The current status of each components:
- seafile: the client syncing daemon. It installs seaf-daemon binary, libseafile library and a few header files. The library and headers are used by the GUI (seafile-client project).
- ccnet: ccnet daemon for the client. It installs ccnet binary, libccnet and ccnet header files.
- seafile-client: the client GUI. It relies on seafile and ccnet libraries and headers files.
- seafile-server: server core. It only installs seaf-server binary. No library or header files installed now. But it still installs python libraries.
- ccnet-server: ccnet-server daemon for the server. It installs ccnet-server binary, libccnet and ccnet header files. Python libraries are also installed.
So currently ccnet-server and ccnet still installs conflicting libraries and header files. But by now the libraries and headers are the same. In the future, only libraries and header files from ccnet-server project may be updated. So we suggest to use libraries and header files from ccnet-server project. Libraries and headers from ccnet-server will be compatible with the ccnet client.
Thanks for the updates do you have any schedule to remove all conflicting files, for instance between ccnet and ccnet-server ?
I don’t think that would be done in short time. Since we don’t anticipate any changes to client ccnet headers and libraries, you can use ccnet-server headers and libraries for client too.