Practical Questions: Maintaining the Arch linux Sonarr package

Help & Support
#1

Update / TL;DR

  1. First point, semantics and conventions aside, /opt is probably not an option if we want Sonarr to make an appearance inside Arch’s official community repo (like nzbget).
  2. -data is here to stay unless it gets officially deprecated.

I deleted some info I deem irrelevant. Check the history of my edits if you need context.

Situation

I approached the current package submitter @justin8 from Arch Linux’s Arch User Repository (AUR) that contains packages such as Sonarr that once good enough can be moved into the official community repository, if there are no licensing issues (GPL3) and if enough votes are made.

Currently the Sonarr package in the AUR installs Sonarr into /usr/lib/sonarr. Systemd starts exec mono /usr/lib/sonarr/NzbDrone.exe -nobrowser -data=/var/lib/sonarr from /bin/sh (Arch Linux maintained mono) using user:group sonarr:sonarr.

Following concerns have been mentioned:

  1. Sonarr’s update functionality does not work. Packages inside /usr/lib are not supposed to receive write access from unprivileged users (see below). The Sonarr installation could maybe be moved to /opt to allow self-updates but that certainly would not help the chances of making an appearance in Arch’s official community repository.
  2. @Taloth mentioned the -data function is not recommended for production environments. Looking through the code I could not particularly tell why, it is hard to search for “-data” anywhere (forums or google). Is it not recommended because it is less robust for potential future changes? The /opt approach could probably circumvent this as well.

The main question

Mainly I wanted to ask about the -data concern. It might be worth noting that it would be Arch Linux’s responsibility to very simply migrate existing configuration to new locations if configuration layout changes were to occur.

#3

The package currently in AUR was originally written by me back when it was called nzbdrone. I made this decision based on how e.g. chromium (/usr/bin/chromium shell script that eventually execs /usr/lib/chromium/chromium) and firefox (/usr/bin/firefox is a symlink to /usr/lib/firefox/firefox) are packaged in the official repositories. I think that’s authoritative enough to use as an interpretation of the Arch Linux packaging guide lines. Even so, some things probably belongs in /usr/share strictly speaking, but this was the best compromise I could make without modifying the upstream source code :slight_smile:

At any rate, I’ll follow this as the sonarr package maintainer. I would like to request that the --data option remains though. I think it’s a pretty clean way of separating the application from its data. Alternatives would be a configuration file in /etc or an environment variable.

#4

Hey man, thanks for coming over here (person that is registered 10 times as long as I have)! Indeed a --data option makes a lot of sense. Hope you don’t think I actually suggested moving the UI into share, that would be madness.

Edit

Frankly, after reading the packaging standards carefully, the only way for Sonarr to make an appearance inside the community repo is the way you did it. That only leaves the question with whether -data will be deprecated or not. I will try to edit the initial post as much as I can.

#5

Oh, no. That would be way overkill without upstream support. Minimal modification is also a part of The Arch Way.

#6

/me likes that guy

#7

–data is not officially a supported argument, it’s only used in our automatic test environment. Consider it a development option, not a production option. We don’t intend to remove it, we just rather not have it in any production environments.
The problem is that it won’t be preserved in the restart after an update and possibly other restart scenarios, which might not apply on arch, but still something that should be kept in mind.

I also think it doesn’t matter, you already set /var/lib/sonarr as home dir, why not let sonarr add ./.config/NzbDrone and store it’s data there?

As for the writable binaries dir, sonarr will need it if you want to do auto updates from within the app. By default the ubuntu package isn’t writable either, so it’s the same in that respect.
But if you want auto updates you’ll have to make it writable, whether it’s /opt or /usr, that’s not my concern. You can also leave it readonly but then you’ll have to be clear that auto-updates won’t function.

#8

@degeberg

Tested removing -data and it works (while still having the shell set to /bin/false). I would recommend keeping the files where they are right now but creating a symlink /var/lib/sonarr/.config/NzbDrone -> /var/lib/sonarr.

PKGBUILD

--install -d -m 755 "${pkgdir}/var/lib/sonarr"
++install -d -m 755 "${pkgdir}/var/lib/sonarr/.config"
++ln -s "${pkgdir}/var/lib/sonarr" "${pkgdir}/var/lib/sonarr/.config/NzbDrone"

/usr/lib/systemd/system/sonarr.service

--ExecStart=/usr/bin/sonarr -nobrowser -data=/var/lib/sonarr
++ExecStart=/usr/bin/sonarr -nobrowser

That would even make sure that /var/lib/sonarr/.config is owned by root:root.

In IRC we talked about implementing the auto-update by supplying a script to run pacman or build from AUR so users can use the scripted up-date instead of the built-in method.

Though despite changing this, the restart does not seem to work with systemd for me, I’ll look into it.

#9

Personally I don’t think it’s a good idea to symlink back to $HOME, it’s confusing and is a recursive link.

#10

I have to agree with @taloth on the symlink thing. But I would be happy to remove the -data option if it just writes to .config in the user’s home directory. But it wouldn’t really provide any benefits in the current situation, we still can’t auto update or restart the service from the webui.

#11

@Justin8
Without the symlink we could drop the -data option and Sonarr would use /var/lib/sonarr/.config/NzbDrone as the directory for settings instead of /var/lib/sonarr and at least the requirements for the Web-UI’s auto restart would be met. Why that does not work yet, is another (hopefully easy) issue.

Whether we change things or not is not up to me. I will leave that up to you guys, @Taloth, @degeberg and @Justin8.

The reason I recommended the symlink is that that way users would not run into trouble finding Sonarr’s configuration inside /var/lib/sonarr. Another thing to note is that dropping -data is not only a requirement for the auto-start if we find the issue but also for potential updates using the scripted method rather than built-in updates.

Thanks everyone for the time and effort. This should probably be a one time thing and can be applied for other distros as well for future reference.

#12