Package Details: ccnet-server 7.1.5-2

Git Clone URL: (read-only, click to copy)
Package Base: ccnet-server
Description: Internal communication framework and user/group management for seafile server
Upstream URL:
Licenses: GPL2
Conflicts: ccnet
Provides: ccnet
Submitter: eolianoe
Maintainer: None
Last Packager: Joffrey
Votes: 96
Popularity: 0.000004
First Submitted: 2017-01-07 14:58
Last Updated: 2020-12-05 11:00

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

Joffrey commented on 2018-02-26 11:21

@all Some dependencies have been updated. The stability can not be guaranteed, you can wait for the next update.

blubbblubb commented on 2018-02-15 02:42

Have a look at the other comments starting with: 2018-02-08 10:01

there were some significant changes to how the packages interact and depend on each other

I assume your problem is that you can't update your system right now? If you are using only the client:

pacman -Rdd ccnet-server

should fix your problems, after that you can update ccnet (and seafile) again

hopimet commented on 2018-02-13 19:14

I think there a problem with the version which is in conflict with ccnet-server. Shoudn't it be 6.2.5 instead of 6.1.5?

klemens commented on 2018-02-13 18:41

This now needs an additional libevent dependency, otherwise the configure fails. Also it seems libmariadbclient is not needed, as configure does not mention it and it builds fine without.

Joffrey commented on 2018-02-09 15:32

@eolianoe You're right, I could rename the headers .. and propose something to upstream but if it is not accepted it will be time lost. So for the next update:

CLIENT = ccnet        + seafile        + seafile-client
SERVER = ccnet-server + seafile-server + seahub 

eolianoe commented on 2018-02-09 14:24

@Joffrey: let's try the conflict thing by keeping only the needed libraries/includes by the client and the server until upstream move to a more clean way to distribute their software

Joffrey commented on 2018-02-09 09:18

Ok thanks, yes in according to this post we can use ccnet-server instead ccnet and seafile-server instead seafile.

But I think that would only repel the problem. One day the client will have a different function of the server and the situation will be the same.

Yes it that for the commit. I do not like the idea to put the client and server in conflict me too.

Up your issue is the only thing to do.

Edit: Replace seaffile by seafile-server is not possible (see) Are we respecting 'Arch packaging standards' if we change the libdir? ie for ccnet-server:

build () {
  cd "${srcdir}/${pkgname}-${pkgver}-server"
  ./configure \
      --libdir=/usr/lib/ccnet-server \
      --prefix=/usr \
      --enable-ldap --enable-python --enable-console \

eolianoe commented on 2018-02-09 07:49

  1. is a lot of work and it's easier to follow upstream rather than rewrite their software
  2. no idea if it's a common use to have both on a machine but I'm not in favor of forbidding this idea, however if it's the only solution let's do it.
  3. according to this post the ccnet-server should be used for both client and server. Besides, this commit should make ccnet-server compatible with seafile-server?

Joffrey commented on 2018-02-08 22:51

I understand, but since ccnet-server/seafile-server v6.2.5 the libs rpc are not the same as ccnet/seafife. See e16e5401e (thanks @Klemens). Seafile-server was unusable I had to put seafile in conflict...


  1. make seafile-server portable (maybe not obvious and update more complicated)
  2. Put seafile-server and seafile-client in conflict (It is true the machine couldn't be client and server, but it isn't current to use the client and the server on the same machine in production :? . For tests the virtualization is possible)
  3. Are you an idea ?

eolianoe commented on 2018-02-08 19:57

@Joffrey: this a good idea but that implies that you can't have both the server and the client on the same machine as the client needs ccnet and the server needs ccnet-server but both are conflicting with your PKGBUILD