Hi bill-auger
My apologies, I didn't know if it was a housekeeping issue moreso than a packaging request, so sorry for the miss-title, Given that the jami-libclient package is now redundant in future builds. I thought this might have been what was discussed by yourself and bandali in https://labs.parabola.nu/issues/3051 and might have been preventing parabola from following the nightly like arch does.
Anyhows thank you anyway

Ryan

I didn't know if it was a housekeeping issue moreso than a packaging request,

really, it is neither - it is simply an out-of-date package; but there is no category for that on the bug tracker - those should be flagged on the packages website; and are not not important enough to deserve a ticket, unless the out-of-date package is broken or un-installable

if "follow the nightly" means un-versioned VCS builds, we always try to avoid that as a matter of policy - arch normally does also - VCS builds should be reserved for emergency situations - jami makes proper releases; but much less often than the arch packages are upgraded - the last sourceball on ftp.gnu.org was november 2021; so AFAIAC, the parabola version is still further ahead than it should be - rather than "outdated", it is actually "pre-dated"

i was hoping that the parabola package would be a one time release; but now it looks that the arch package strictly depends on webengine (and is still built from VCS), so it may need to remain on the blacklist indefinitely

i will need to look into this more - bundling the client libs with the daemon, but keeping the client separate (especially that it is the only compatible client), that does not smell quite right to me - i think we should wait until there is a new stable release to sort this out

I believe that they keep the daemon part separate so that the other clients such as android, ios and windows are able to use the same dameon/libs but have different clients, so that may be why it might seem a little odd?

it makes sense to package the client libs separately
to allow for a variety of multiple clients - it is odd to
package the server with the client libs, unless some client is
also in the package - quassel is an example

quassel-common    # the client libs
quassel-core      # the daemon
quassel-client    # a client
quassel-client-qt # another client

quassel-monolithic    # quassel-core + quassel-common + quassel-client
quassel-monolithic-qt # quassel-core + quassel-common + quassel-client-qt

$ pacman -Sii quassel-core | grep Required
Required By     : None

in that way, no clients depend on the daemon being installed
locally - the daemon may be running on a separate machine,
on a router or home-server for example, so that multiple clients
can be the interface of the same real session - AFAIK, jami is
also designed to be used that way

I think that because Jami doesn't use a client-server model and being p2p and distributed using the DHT, it means each instance of JAMI on a desktop or mobile device runs those functions, which is probably why this is so?. I think this is the way tox operates aswell, by having toxcore to do the backend stuff and having the clients of which there are a variety which all use toxcore.

but it is a client-server model - the daemon is the server - the difference is that there is not a single centralized server, which every client connects to; but each user runs a server

with typical p2p software, the client and server are the same application - your client does not connect to your server (itself); but to other people's servers, and other people's clients connect to your server - with jami, the client and server are separate programs - both your client and other people's clients connect to your server; and your server does not need to be running on the same computer as your client(s)

i have not looked into it, but maybe arch is compiling it, such that the daemon needs to be running on the same computer as the client - if that is the case, then it is effectively disabling a feature - but if that is the case, the client and daemon could be one single package, like a typical p2p application; because each is useless without the other, and no alternative clients exist - if there is only one possible client, and if there were to be exactly two packages; the logical split is with the daemon in one package and the client libs and GUI in the other package

there was an alternative client (the GTK client); but the upstream is not maintaining it anymore - if the GTK client was going to remain viable, then we would probably not be discussing this now - parabola would simply replace the QT client in arch with the GTK client

i just discussed this with the jami devs - there was a stable release today; which effectively obsoletes the GTK client

the client libs were absorbed by the QT client upstream - they are not in the daemon package, which makes much more sense; though that change makes it more difficult now, for any alternative clients to be written