Package Details: sonarr

Git Clone URL: (read-only)
Package Base: sonarr
Description: PVR for newsgroup users
Upstream URL:
Licenses: GPL3
Submitter: justin8
Maintainer: degeberg
Last Packager: degeberg
Votes: 80
Popularity: 0.25
First Submitted: 2014-11-10 04:45
Last Updated: 2019-08-17 05:50

Dependencies (9)

Required by (5)

Sources (4)

Latest Comments

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

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.

SAKUJ0 commented on 2015-04-13 08:45


I will approach the developers patiently (I don't see any rush with this, arch would be my recommended way to use Sonarr right now *because* of the package you maintained, so thank you again).

The Sonarr devs are a bit more Windows centric (they use Linux too of course). From what I gathered and interpreted they would mostly prefer an /opt approach. I believe Arch hates an approach like that but if it is ever warranted, it would probably be here (after all all Sonarr files are in one directory to my knowledge and it would probably solve the -data thing, too - let's not change anything without making sure to do things right, I will talk to the devs and find a forum post).

My apologies for the /usr/lib thing. Of course we cannot give write access there, I was mixing things up when compiling things and for that moment I was thinking we were talking about /var/lib so best just ignore that suggestion.

Let me come back at you later. I thought I'd let you know you are of course right directly.