Package Details: sonarr-bin 4.0.13.2932-1

Git Clone URL: https://aur.archlinux.org/sonarr-bin.git (read-only, click to copy)
Package Base: sonarr-bin
Description: Smart PVR for newsgroup and torrent users
Upstream URL: https://sonarr.tv
Licenses: GPL-3.0-or-later
Groups: servarr-bin
Conflicts: sonarr
Provides: sonarr
Submitter: txtsd
Maintainer: txtsd (fryfrog)
Last Packager: fryfrog
Votes: 104
Popularity: 3.01
First Submitted: 2024-10-13 20:06 (UTC)
Last Updated: 2025-02-12 17:46 (UTC)

Dependencies (20)

Required by (17)

Sources (8)

Pinned Comments

mkomko commented on 2024-11-15 06:59 (UTC)

PSA: If you receive exceptions like "System.IO.IOException: Read-only file system" when Sonarr is importing files after updating to 4.0.10.2544, and you use your home directory for downloaded files (which is advised against), you can either move file management out of your home directory or do something like the following:

$ sudo systemctl edit sonarr

[Service]
# Allow home directory path to be writable again
ReadWritePaths=/home/user/media

txtsd commented on 2024-10-21 03:56 (UTC) (edited on 2024-10-30 12:50 (UTC) by txtsd)

Alternate versions

sonarr (source version of this package)
sonarr-develop (develop branch)
sonarr-develop-bin (binary version of the develop branch)

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 Next › Last »

justin8 commented on 2015-04-13 09:59 (UTC)

@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.

degeberg commented on 2015-04-13 09:52 (UTC)

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 (UTC)

@justin8 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 (UTC)

@justin8 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.

justin8 commented on 2015-04-13 00:40 (UTC)

@shkercuh Your one builds in to /opt so it isn't really an issue. /opt is really the catch-all for things that don't comply with the usual standards. check man file-hierachy for more details. It does state that /usr is not required to be read-only. But working in a corporate Linux environment I would have some words with anyone who tried to make an app write to /usr. (FYI, I'm the maintainer for the sonarr-develop package on the AUR) @SAKUJ0 the -data/-datadir thing is needed to write the files to the correct place of /var unless we ran the whole application out of /opt. Since it does appear to support working in this manner, are you able to link to those forum posts you said about the developers recommending against using it?

shkercuh commented on 2015-04-13 00:31 (UTC)

@justin8 @SAKUJ0 Is the approach I have taken in https://aur.archlinux.org/packages/sonarr-git correct?

justin8 commented on 2015-04-13 00:29 (UTC)

I feel I should point out that regardless of the developers wishes, no programs at all should be able to write to /usr. It is static data that should be maintained in your package manager and not transient data. That belongs in /var. Having an auto update system within the app instead of using the OS package manager is a windows/OSX thing that is somewhat against the Linux way of managing things. The correct way to update an app is to update it via the package manager. If auto updating is something they want, it should be living in /opt where other non-conformant apps live.

SAKUJ0 commented on 2015-04-12 17:24 (UTC)

Hey, thanks for maintaining the package. A few obvious and not so obvious points the developers of Sonarr pointed out to me when I mentioned the AUR package: 1) It would be really great if /usr/lib/sonarr had write access to the sonarr user. That is a requirement for the desired update functionality to work within Sonarr and update procedures seem to be fine with the way the installation is set up. 2) Currently using -data / -datadir (I don't recall exactly) is not recommended by the Sonarr devs in production environments. The devs pointed me towards the forums as ongoing discussions appear to be there for best ways how to avoid using the launch option. 3) The distro repo for mono can cause SIGSEGV issues. Currently it is recommended to use mono 3.10.0 instead of 3.12.1 or at least the current git version of 3.12.1. That being said, I myself am using the distro version (3.12.1) of mono just fine so I prefer the currently used mono version myself. I just thought I would mention this. Of course I can supply you with patches but in the spirit of the AUR, which emphasizes collaboration and the learning curve, I thought it would be best to approach you for the reasons of doing things the way they are. Maybe we can handle things more the way the devs of Sonarr would recommend, without going against Arch and AUR conventions. At least making sure the update functionality works (the devs are very conservative with patches) would certainly be a desirable goal.

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 Next › Last »