Now that we have a separate "pelican-server" binary, we should put it in our packaging (RPMs, Debs, APKs). Awkwardly, we already have a package called "pelican-server", but that just includes systemd files and config files for the individual components (e.g. /etc/pelican/pelican-cache.yaml). Presumably we will be modifying the systemd files to use the pelican-server binary instead of the pelican binary.

I see three options for packaging (I'm using RPM as an example but we should also do Debs):

1. Put the pelican-server binary in the pelican RPM (same as the pelican binary).

2. Put the pelican-server binary in the pelican-server RPM (same as the systemd configs).

3. Put the pelican-server binary in its own RPM (say, "pelican-server-progs").

The advantage of choice 1 is that neither the pelican-server RPM nor the osdf-{cache,origin,director,registry} RPMs will gain any dependencies. The downside is that admins won't be able to upgrade the client and server separately (which was one of the things we were hoping to get from splitting out pelican-server).

The advantage of choice 2 is that it's obvious (pelican-server contains pelican-server), and the pelican-server RPM won't gain any dependencies. Unfortunately, the osdf-{cache,origin,director,registry} RPMs will gain a dependency on pelican-server, which will result in people installing, say, just osdf-cache, but also getting systemd files for pelican-origin, pelican-cache, pelican-director, pelican-registry.

The advantage of choice 3 is that it's a clean separation and doesn't have the previously mentioned downsides. The disadvantage is that it's yet another RPM in our already large list of artifacts. The dependencies of pelican-server and osdf-* will have to be updated.

I personally think 3 is the best choice here.