please avoid symlinks / breaks Debian packaging

[adrelanos]

https://github.com/rustybird/corridor/commit/5c0cf80c5819b39778df7036d6d5774250690a48 broke Debian packaging. (#10)

 dpkg-source -b corridor
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building corridor using existing ./corridor_20160710131757.orig.tar.gz
dpkg-source: error: cannot represent change to qubes/systemd/corridor-init-logged.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: cannot represent change to qubes/systemd/corridor-init-forwarding.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: cannot represent change to qubes/systemd/corridor-init-snat.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: cannot represent change to qubes/systemd/corridor-data.service.d/qubes-service.conf:
dpkg-source: error:   new version is symlink to ../corridor.target.d/qubes-service.conf
dpkg-source: error:   old version is symlink to corridor-20160710131757./corridor.target.d/qubes-service.conf
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b corridor gave error exit status 2
debuild: fatal error at line 1376:
dpkg-buildpackage -r/home/user/Whonix/packages/corridor/debian/gain-root-command -D -us -uc -sa failed

Symlinks are somewhat non-ideal.

Can this be better expressed using text configuration files without any symlinks?

[rustybird]

Not sure what's happening there, but I find it hard to believe that Debian packaging can't deal with relative symlinks.

Somewhat related -- maybe you've seen it, I'm publishing (gasp) version numbers now and switched to the Debian/Fedora control connection defaults. Would it not be easier at this point to just package corridor "in the usual fashion"? Like,

1. Fetch the sources
2. Build the systemd units: make PREFIX=/usr
3. Install it to some temporary directory: make PREFIX=/usr SYSTEM=/lib/systemd/system DESTDIR=... install install-systemd install-qubes
4. Do whatever fix-ups are still needed for Debian inside the destination directory

This would also spare you from merge issues whenever I reorganize the repository tree.

[adrelanos]

I made good progress. (git commits attached above.)

1. Build the systemd units: make PREFIX=/usr

Was this sentence right? What would that be good for or what is it actually doing? I am not currently using that. Perhaps that causes the below issue.

---

The replacement inside the systemd unit file (example) does not work yet. I.e.

ExecStart=SBIN/corridor-data

gets actually replaced to:

ExecStart=/usr/local/sbin/corridor-data

But it should be replaced to for example: ExecStart=/usr/sbin/corridor-data

The relevant build log:

+ make -f Makefile_orig PREFIX=/usr SYSTEM=/lib/systemd/system DESTDIR=/home/user/whonix_dot/Whonix/packages/corridor/debian/corridor install install-systemd install-qubes
make[2]: Entering directory '/home/user/whonix_dot/Whonix/packages/corridor'
install -d /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/usr/sbin /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/usr/share/man/man8 /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/etc/corridor.d /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/var/lib/corridor
install sbin/* /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/usr/sbin
install -m 644 man/corridor.8 /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/usr/share/man/man8
for f in sbin/*; do ln -sf corridor.8 /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/usr/share/man/man8/${f##*/}.8; done
install -m 644 corridor.d/* /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/etc/corridor.d
install -d /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/lib/systemd/system
install -m 644 systemd/corridor-data.service systemd/corridor-init-forwarding.service systemd/corridor-init-logged.service systemd/corridor-init-snat.service systemd/corridor.target /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/lib/systemd/system
install -d /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/etc/corridor.d /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/lib/systemd/system
install -m 644 qubes/corridor.d/* /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/etc/corridor.d
umask 022 && cp -RP qubes/systemd/* /home/user/whonix_dot/Whonix/packages/corridor/debian/corridor/lib/systemd/system
make[2]: Leaving directory '/home/user/whonix_dot/Whonix/packages/corridor'

I could manually work around that issue, but before I am doing a custom sed, I am wondering how to correctly use the following part of your original makefile.

%.service: %.service.in
    sed 's:SBIN/:$(SBIN)/:' $< >$@

Somehow I am using it wrong?

[rustybird]

1. Build the systemd units: make PREFIX=/usr

Was this sentence right? What would that be good for or what is it actually doing?

That's the default target systemd-units, i.e. what actually bakes in the right directory into the systemd units. You could skip this command, because it is also a dependency for the install-systemd target, but I think distributions like to keep the build phase separate from the installation phase. (Though in this case the build phase is kind of trivial.)

The relevant build log:

It looks like the build directory is dirty, i.e. .service files from a previous build/installation (where you maybe hadn't passed PREFIX=) are still lying around. Try make clean.

[adrelanos]

Right. (The .gitignore confused me.) Properly running make clean now. The dpkg-source symlinks issue is now also worked around. Although I still do not like the symlinks, it is now good enough for Debian packaging (#10).