Advice on handling optional dependencies or packaging yp-tools

[Kyle Andrews <kyle@posteo.net>]

Dear Guix,

I'd like to be able to have access the yp-tools package with Guix from a
foreign distro. Particularly, I want to be able to call yp-cat since I
have placed some optional functionality which does this in an R
package using it's `system` command.

I had been using yp-cat on Ubuntu (where I use Guix as a foreign distro)
to help get some additional data about the meaning of some registration
codes setup and configured and provided by the network administrators. I
am not knowledgeable about networking and just want to package up my
workflow on Guix while also perhaps being able to have the shell environment fall through to the Ubuntu yp-tools configuration if it's not available in Guix.

I'm guessing that the output from yp-cat would be fairly installation
specific, and I am not relying on it for the workflow. It's just their
because some optional R code can use it if it's available which will
otherwise error.

R tends to inject some library paths into it's system calls in
`/gnu/store/*-r-minimal-*/lib/R/etc/ldpaths`. However, I can override
this by including an .Renviron file that can set LD_LIBRARY_PATH
explicitly or I can set it directly at system call time. Maybe this is
the right way to go about it? Just use the Ubuntu version and ignore
this input from Guix? Does or should Guix support specifying metadata
which would say that something was a passthrough dependency to a library
on a foreign distribution?

I'm seeking guidance on what the best approach for dealing with this
would be. If the package is pretty simple to write and it's just a
matter of me needing to learn how to work through making a few
substitutions in the source code I would be happy to go through that
exercise. If not, then at least I want to record what my approach was in
the hopes it might inspire others to try and verbalize their packaging
strategies so that it becomes easier for new users to get started in the future.

The package uses autotools and friends. I thought I had figured out most
of the build dependencies. However, now I'm not so sure. The current
error mentions the libcom library which in debian depends on epics-base
and doesn't appear to be provided by Guix.

Here is what my package looks like so far.

```
(use-modules
 (guix git-download)
 (guix packages)
 (guix build utils)
 (gnu packages gettext)
 (guix licenses)
 (gnu packages m4)
 (gnu packages base)
 (gnu packages kerberos)
 (guix gexp)
 (gnu packages onc-rpc)
 (gnu packages crypto)
 (gnu packages pkg-config)
 (gnu packages autotools)
 (guix build-system gnu))

(package
 (name "yp-tools")
 (version "v4.2.3")
 (source
  (origin
   (method git-fetch)
   (uri (git-reference
	 (url "https://github.com/thkukuk/yp-tools.git")
	 (commit version)))
   (file-name (git-file-name name version))
   (sha256
    (base32 "1gbh03sfp05hh9qfg95qf22x5zvfalf20am48g4r4rprv9n3vm3v"))))
 (build-system gnu-build-system)
 (arguments
  (list
   #:phases
   #~(modify-phases %standard-phases
       (add-after 'unpack 'fix-varyp
	 (lambda _
	   (substitute* `("etc/Makefile.am")
	     (("varypdir = /var/yp")
	      (string-append "varypdir = " #$output "/var/yp")))
	   #t)))))
 (native-inputs
  (list m4
	automake
	autoconf
	mit-krb5
	libnsl
	libtirpc
	libxcrypt
	binutils
	gettext-minimal
	pkg-config
	libtool))
 (description #f)
 (home-page #f)
 (synopsis #f)
 (license gpl2))
```

grep'ing for other locations with hardcoded values for /var/yp I saw
${SOURCE}/src/yp_dump_binding.c and ${SOURCE}/etc/nicknames.h. I suppose
they would also need to be substituted like above.

I'm not very familiar with autotools or how to think about it. I read
the gentoo overview which helped give me the big picture of how
makefiles and configure scripts are generated portably, but it didn't
give me any further insights towards actually patching a program.

=> https://devmanual.gentoo.org/general-concepts/autotools/index.html

The more effective thing I did was search through the Guix source code
for packages which might serve as examples. The thing which seemed the
most effective was to look through packages under lines with (add-after
'unpack ...) in them.

I also thought to read the packages made for Debian and Arch Linux.

=> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=yp-tools
=> https://packages.debian.org/bullseye/yp-tools

I was confused that libcom was not listed as a dependency on Debian.

=> https://packages.debian.org/sid/libcom3.17.6
=> https://github.com/epicsdeb/epics-base

I tried to package up epics but I didn't get far.

```
(use-modules
 (guix git-download)
 (guix packages)
 (gnu packages perl)
 (guix build utils)
 (guix licenses)
 (guix gexp)
 (gnu packages pkg-config)
 (guix build-system gnu))

(package
 (name "epics")
 (version "3.15.6")
 (source
  (origin
   (method git-fetch)
   (uri (git-reference
	 (url "https://github.com/epicsdeb/epics-base.git")
	 (commit "c595b238d04c7f5aaa739c9a6976487709d952bd")))
   (file-name (git-file-name name version))
   (sha256
    (base32 "0knck7gw6m93881vm7hqf50wl9ccka3rqny71k7p88z59vhfdyri"))))
 (build-system gnu-build-system)
 (arguments
  (list
   #:phases
   #~(modify-phases %standard-phases
       (delete 'configure))))
 (native-inputs
  (list pkg-config perl))
 (description #f)
 (home-page #f)
 (synopsis #f)
 (license #f))
```

It seems to have a whole configuration directory instead of just a
./configure script.

Another issue is that this package uses a custom license and I'm not
sure whether it is a variant of one of the existing licenses or if there
needs to be an additional entry in Guix licenses.

That was a bit of a mouthful. Obviously, after packaging epics, libcom
would also need to be packaged. I will stop there and see if anyone
thinks they might be able to offer some advice.

Thanks,
Kyle