Package Details: sonarr

Git Clone URL: (read-only, click to copy)
Package Base: sonarr
Description: TV download automation for usenet and torrents.
Upstream URL:
Licenses: GPL3
Submitter: justin8
Maintainer: degeberg (fryfrog)
Last Packager: fryfrog
Votes: 82
Popularity: 0.63
First Submitted: 2014-11-10 04:45
Last Updated: 2021-03-27 22:34

Required by (7)

Sources (5)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 Next › Last »

SAKUJ0 commented on 2015-05-26 14:49

Package works updating the pkgver to


and issuing a `updpkgsums` into 3b9493499dccde7acd259dcc6582cc9c (md5sum) etc.

I would recommend editing the .install to store files inside /var/lib/sonarr/.config/sonarr, rather than inside /var/lib/sonarr, which allows to remove the -data option in the service file, as was suggested by Taloth earlier.

SAKUJ0 commented on 2015-05-25 11:14

Do you need some help with the package?

While we are at it, we could follow Taloth's advise this time and mv /var/lib/sonarr/* to /var/lib/sonarr/.config/sonarr (IIRC), getting rid off the redundant data switch.

justin8 commented on 2015-04-13 22:35

No problem. Thanks for querying these things. Sometimes packagers overlook simple solutions to things and its helpful. Glad you got a chance to learn something as well.

SAKUJ0 commented on 2015-04-13 11:58

@justin8 I just wanted to add how right you were about /usr (maybe even more right than you would expect).

This does not belong into /opt and I would say write permissions inside /usr are not an option. Props to you and degeberg. Thanks to you guys I have learned something.

SAKUJ0 commented on 2015-04-13 10:37

@justin8 I made a post in the Sonarr forums, mainly about the -data 'concerns':

I don't argue with anything the two of you have said. Hope I managed to deliver the information appropriately that I mainly wanted to ask for the current reasons to do things the way they are instead of supplying patches or coming up with 'better' or 'right' ways to do things.

Let's see if they go as far as to officially deprecate the -data option. I'll keep you posted, in other words consider all my questions answered and I would update you if we hear anything relevant.

Thanks for the quick responses!

justin8 commented on 2015-04-13 09:59

@SAKUJ0 There is no link there. Not sure if you didn't post it or if the AUR removes external links in comments these days.

The /usr / /var seperation is more of a security thing. Application binaries can't be updated outside of root running your package manager (in a perfect world) Meaning that combined the package signing system you (should) always have trustworthy and immutable programs. It's one of the many ways that Linux is more secure than Windows/OS X by default. If possible I would like to keep the sonarr-develop (and preferably all of the sonarr* packages) not having to use opt since there is an alternative that is more secure.

justin8 commented on 2015-04-13 09:56

@SAKUJ0 There is no link there. Not sure if you forgot to paste it or if the AUR removes external links in comments these days.

justin8 commented on 2015-04-13 09:55

@SAKUJ0 There is no link there. Not sure if you didn't post it or if the AUR removes external links in comments these days.

degeberg commented on 2015-04-13 09:52

I'll have to agree with justin8 on the auto-update thing. It's the package manager's job to keep track of updates and such. In fact, the mono problem you mentioned is a compelling reason to not have applications auto-update themselves. Using the package manager, one can simply opt to either not upgrade sonarr or mono until they're compatible. That being said, I have not personally experienced any problems using the latest repo version of mono along with the latest upstream version of sonarr.

As for the --data option, unless its being officially deprecated for future removal, I don't see any reason not to use it. It actually works great for this purpose, which was the reason why I originally made it this way. Separating application binaries from application data is a much more standard Linux/Arch way of doing things. I even believe that's the case on Windows nowadays as well. If they remove --data without providing an alternative, I'll be forced to move it to /opt of course, but I definitely think it'll be a step in the wrong direction.

SAKUJ0 commented on 2015-04-13 08:48


I am searching the forums right now here is the thing I am referring to, by the way

<@Taloth> yes, but the --data option shouldn't be used in production environments either. you might wanna check our forum, might have a discussion on it.