Packaging Request #3012

add 'gophernicus' to PCR

botplus - 2 months ago - . Updated about 2 months ago.

% Done:



i see there is no gopher server or client in package repositories. i've came across gophernicus in sdf commode chat. here is its home and github pages:


PKGBUILD (803 Bytes) PKGBUILD botplus, 2021-04-18 02:29 AM
Makefile (5.92 KB) Makefile botplus, 2021-04-18 02:50 AM



Updated by takuwan 2 months ago

I do not know for a Gopher server, but there is the lynx text browser that can be used as a Gopher client. It is in the [extra] package repository. I have not used it for Gopher myself though.


Updated by bill-auger 2 months ago

rhere is also the 'snarf' client


Updated by botplus 2 months ago

i've been able to build and install a gophernicus package with the attached PKGBUILD. one little thing though, Makefile line 175 uses DESTDIR in a way that i don't quite understand, after installation, i just delete the DESTDIR part in the path to the executable, in the installed service file /usr/lib/systemd/system/gophernicus@.service. i've tested systemd only, server seems running just fine.


Updated by bill-auger about 2 months ago

  • Priority changed from bug to wish
  • Subject changed from gophernicus to add 'gophernicus' to PCR

it would be good to have a gopher server in the repos - i dont believe that there is one now - i found two gopher servers in the AUR: 'motsognir' and 'sgopherd-git' - have you ever tried either of those?

  • 'gophernicus' is BSD-licensed, written in C
  • 'motsognir' is GPL-licensed, written in C
  • 'sgopherd' is MIT-licensed, written in BASH

the are more important considerations also, such as the feature-set and good documentation, which i have not looked into

all three are relatively mature and actively maintained - are there any convincing reasons known already, why 'gophernicus' should be preferred? - or maybe we should consider the others


Updated by bill-auger about 2 months ago

  • Assignee set to bill-auger
  • Status changed from open to in progress

the licensing looks good; and after some patching, it compiles and runs as expected (tested with openrc+xinetd) - multiple service files can be configured; but i chose the 'xinetd' mechanism, because parabola already has openrc support for xinetd

changes to the proposed PKGBUILD:

  • `--sbindir=/usr/bin` must be passed to ./configure, in order for the package to be installable on an arch system
  • changed the server root to: /srv/gopher

patches added:

  • remove-DESTDIR-from-initscripts.patch - the reference to the DESTDIR path, in the systemd init script, is a bug - the same bug is repeated in the other init scripts
  • fix-make-log-typo.patch - typo in the 'install-msg-xinetd' rule log - this patch does not affect the binary package, but it should be in the source-ball
  • xinetd-respect-custom-server-root.patch - with the combination of the `--listener=xinetd` and `--gopherroot=/srv/gopher` options, the server was broken; because '/var/gopher' is hard-coded into the xinetd service file, regardless of the config option to customize it - rather than a crude `sed` change in the PKGBUILD, i made a patch for the proper solution
  • preserve-existing-gophermap.patch - while fixing the previous critical bug. i stumbled upon another - this one would not affect the binary package either - the configure script checks for an existing server root directory, then triggers the 'install-root' Makefile rule to fire, which clobbers the existing 'gophermap' (the opposite of the stated intention "Don't replace an existing root")
# Don't replace an existing root
printf "checking for existing gopher root... " 
if [ -d "${GOPHERROOT}" ] || [ -f "${GOPHERROOT}/gophermap" ]; then
    printf "yes" 
    printf "no" 
sed -i -e "s:@INSTALL_ROOT@:${INSTALL_ROOT}:" Makefile

which injects into the Makefile:

install: src/$(BINARY) @CLEAN_SHM@ install-man @INSTALL_ROOT@ @INSTALL_OSX@ \
  (INSTALL) -d -m 755 $(DESTDIR)$(ROOT)
  $(INSTALL) -m 644 $(MAP).sample $(DESTDIR)$(ROOT)/gophermap

presumably, `INSTALL_ROOT="install-root"` should be in the `else` clause - oddly, the 'install-root' will always fire regardless, when the service files are installed, eg: 'install-xinetd' , 'install-systemd', per the analogous injection of 'INSTALL_SYSTEMD' or 'INSTALL_XINETD' in the same 'install:' rule above - therefore, this patch does not actually solve the problem it aims for - it could perhaps be enhanced by the upstream though, to actually avoid clobbering the existing gophermap

in ./configure:
sed -i -e "s:@INSTALL_XINETD@:${INSTALL_XINETD}:" Makefile
sed -i -e "s:@INSTALL_SYSTEMD@:${INSTALL_SYSTEMD}:" Makefile

in Makefile:
install-xinetd: install-root
install-systemd: install-root

Updated by bill-auger about 2 months ago

botplus -

i noticed that you added yourself as the 'Maintainer:' - if this is your plan, do study the changes i made and ask for any clarifications - the next step would be to offer the patches to the upstream, and remove them from the PKGBUILD recipe at some later time, if they are accepted


Updated by bill-auger about 2 months ago

there is a 'gophernicus' package in pcr-testing, if people want to test it


Updated by botplus about 2 months ago

i've only used gophernicus, on openbsd, a relatively short period of time, around one month. i've not used sgopherd and motsognir. and now that i looked them up, i wouldn't say i have
a preference to gophernicus over the other two. overall, they all seem to provide same functionality, and in a similar way. besides the gopher protocol is so simple that the
implementations simply don't differ much from each other. they all seem to provide enough documentation.


Updated by botplus about 2 months ago

bill-auger wrote:

  • `--sbindir=/usr/bin` must be passed to ./configure, in order for the package to be installable on an arch system

yes, i was aware of that actually, i probably passed it as argument when running configure, but forgot to add it to PKGBUILD.

and the rest of the patches make sense to me.


Updated by bill-auger about 2 months ago

  • Status changed from in progress to fixed

Also available in: Atom PDF