Improving Installation Docs / Distribution Methods for Debian #2706
Replies: 10 comments 19 replies
-
provide an install/update script? see qbm and pmm docs for similar ideas accordingly |
Beta Was this translation helpful? Give feedback.
-
|
Can you point me in a specific direction re: qbm / pmm? The only pmm install script I was able to find was for Percona Monitoring and Management . . . which largely just installs Docker for you. |
Beta Was this translation helpful? Give feedback.
-
|
https://metamanager.wiki/en/latest/home/guides/local.html Plex Meta Manager |
Beta Was this translation helpful? Give feedback.
-
|
Ok, what I see there is an incredibly verbose means of installing in a venv, no scripting? This is a great model for getting people to set up a venv, but I'd prefer we figure out some better way of packaging and distributing for Debian that doesn't expect people to do all that. |
Beta Was this translation helpful? Give feedback.
-
|
Did you see #2594 ? |
Beta Was this translation helpful? Give feedback.
-
|
If you provide a package / distribution method for Debian ... how about Redhat/CentOS, SuSE, Arch, and the dozens other Linux distro's? I see the follow possibilities for that, i.e. distro indepent solutions:
High level: more and more distro's are provding / going to provide an immutable version of their OS. So like Android. And then you can't install stuff into the OS anymore, and applications should provide everything they need in a snap / flatpak / docker package. Ubuntu Desktop 24.04 is going to have an immutable version; see https://news.itsfoss.com/ubuntu-all-snap-desktop/ About debian: I installed it (on a Raspi, so RaspberryOS) a few weeks ago, and getting rar-nonfree is still so difficult. Why? So again: debian is not great for beginners. |
Beta Was this translation helpful? Give feedback.
-
|
What I see: Linux newbie's choose some cool but not easy Linux (yes, like Debian), and then ask for help with difficult stuff. I advice them to use Ubuntu. Or docker ;-) A bit like having no driving license/experience, and then choosing a manual gear supercar, and asking for driving instructions. EDIT: that is often at the level that even CLI is new & scary for those users. |
Beta Was this translation helpful? Give feedback.
-
|
Noted, but look at the options as they stand today:
Is building packages for Debian and serving them up via an unofficial repo just seriously that hard? If it is, cool, we'll just steer people to either Install via Docker or Install from Source, but I want to make sure building packages is truly just too hard before giving up. |
Beta Was this translation helpful? Give feedback.
-
Well it should be a starter.
Indeed. Unless ... there is a SABnzbd provided/included script for that. See my other post / discussion.
Indeed. I don't help with that.
Until two years ago, jcfp's Ubuntu PPA did work for Debian. Coincidence? Not anymore, and I don't know why. |
Beta Was this translation helpful? Give feedback.
-
|
Debian really isn't the distribution anyone looking for the latest releases of everything should be using. That said, I do intend to provide backports in debian, but that won't include every minor version - if only because official backports are limited to versions already accepted into unstable and testing. Version 4.1.0 is probably up next, once it has migrated to testing. The recent increase in support questions is more than likely a side effect of the changes to how pip is handled in debian bookworm, with users now pushed towards venv and not knowing what to do now that their previous habit of polluting the system-wide python install no longer works out-of-the-box. |
Beta Was this translation helpful? Give feedback.
-
|
I see. Oke! |
Beta Was this translation helpful? Give feedback.
-
|
Not yet, waiting for 4.1.0 to get into testing (uploaded to unstable on October 5th, should migrate to testing today). |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so it sounds like backports is our best path forward. Soon as we get a 4.x release in backports I definitely want to sync up with you to update our Debian docs to highly recommend pulling SABnzbd from backports over main. |
Beta Was this translation helpful? Give feedback.
-
|
Available in bookworm-backports now (builds of sabctools for architectures other than amd64 still pending): |
Beta Was this translation helpful? Give feedback.
-
|
I'll try to also get 4.1.0 into sloppy backports for debian 11 (bullseye), in addition to the existing backport of 3.7.1 uploaded in February. |
Beta Was this translation helpful? Give feedback.
-
|
To check sabnzbd with snap on Debian:
Easy. No difficult stuff with sources, unrar, par2, etc
|
Beta Was this translation helpful? Give feedback.
-
|
On 2023-10-10 10:46, Safihre wrote:
Is that worth it? No clue how many debian users there are..
I can see for example that there aew about 5000 active Snap users.
Personally I use Debian but I'm fine with the status quo. Others can
have a different view/need.
I guess if it could be a simple "set up and nearly forget" for your
team, maybe it is worth it just because, but otherwise maybe make a link
to register interest at the download page, then you'll discover if
sufficient interest exists [maybe for a next point version onwards]?
Darren
|
Beta Was this translation helpful? Give feedback.
-
|
On 2023-10-10 11:37, jcfp wrote:
And
that's before you start thinking about adding the likes of sabctools
that need to be build for every supported hardware architecture [1].
Good luck getting github to do that for you.
Maybe in that case the options might be:
a. someone writes and updates a reasonably simple guide [the Plex thing
posted recently seemed a good-ish model from a brief glance) -- probably
over my level but maybe such a guide could be semi-generic [e.g. install
the latest version of x by doing y).
or
b. the users of Debian must use a package manager/Docker or if they are
so insistent roll their own version.
The project's limited resources probably can't roll out a red carpet for
everyone. Well, maybe if they send the developers a very large amount of
money but you get the picture.
Darren
|
Beta Was this translation helpful? Give feedback.
-
I generally agree with this statement, but I also feel like we should at least try to have some reasonable options for how users can get more up-to-date versions for major distributions. It looks like the answer for Debian is going to be:
And conveniently, Option 3 is a good general fallback solution for all distributions. |
Beta Was this translation helpful? Give feedback.
-
|
Option 4: If you're experienced with Linux commandline, you run from source, with python-venv. Furthermore: Option 3 & 4 are valid for any Linux distro |
Beta Was this translation helpful? Give feedback.
-
|
On 2023-10-10 18:18, Jeff George wrote:
I generally agree with this statement, but I also feel like we should
at least _try_ to have some reasonable options for how users can get
more up-to-date versions for major distributions.
Oh I agree, but as it won't be me doing the work, I'm reluctant to
necessarily push for something that might have limited use yet be
possibly very time-sensitive. Naturally "more is better" when resources
allow, even if it is a more static-type document or guide, along with
the other options you've raised, which is still "better than nothing".
I am not privy to any statistics, should they exist, about platform and
architecture usage [not searched, so it could be Sod's Law that they are
immediately discoverable]. Maybe that would, if it exists, help
determine prioritisation of resources.
And, of course, "anything" can always be built upon or improved, should
demand and/or available resources exist.
The users should, in any case, be prepared to put a modicum of effort in
for the privilege of using such a wonderful program :)
Darren
|
Beta Was this translation helpful? Give feedback.
-
|
the other issue that many of the debian users have is after they install sab (pick your own adventure), is getting the service setup. many of the debian users that arrive in discord have little to no linux experience.. i've walked several through on doing the venv setup and getting things going, but then that works great for the one time until they want to update sab versions and sabctools is involved because of how strict we are with versions. unrelated, but the whole sabctools and version to install via os package also plagues ich777 docker version of sab as he uses apt to manage packages for his setup, so he has to manually update what gets installed (as he doesnt rely on requirements.txt). |
Beta Was this translation helpful? Give feedback.
-
|
@thezoggy Indeed. Installing "rar-nonfree" on Raspberry OS is still difficult, isn't it? Anyway: my answer would be ... https://snapcraft.io/docs/installing-snap-on-raspbian . So "option 3". |
Beta Was this translation helpful? Give feedback.
-
i've not heard of anyone having an issue of installing unrar on debian. i know ive seen fallout of users when they tried to install from apt, then install from snap. then things go to crap because you have two instances installed trying to use same stuff which then causes issues and they dont realize it when the service wont start. eventually we figure out what happen and have them just nuke one and just use one package manager looking back at discord the issues have been permission issues, getting service to work. then various things on installing.. such as:
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Over the past couple weeks/months -- particularly since Debian 12 was released in June -- we've periodically had people drop by Discord with a story along these lines:
In my assessment, your average user asking for help installing SABnzbd on Debian probably isn't ready to drop what they're doing and learn how to run a python app from scratch, with a venv, and figure out how to run it as a service manually, and keep it up to date, if all they're used to is installing stuff via
apt.So . . how do we help these users?
I know "Just Update The Official Apt Repo Faster" is off the table. I also know "Use the Ubuntu PPA" is apparently off the table. So what are our options?
Is it completely insane to set up our own deb build pipeline through Github Actions? Would it be an immense mess to set up our own apt repo? Should we be directing people to snaps instead? flatpak? I don't know what the best approach is going to be because my approach -- as someone who has been maintaining a handful of personal Debian servers for 20+ years -- has been "if you care about bleeding-edge application versions, use Docker"... so this hasn't been a problem I've had to personally solve.
Pinging @jcfp as our resident Debian/Ubuntu Maintainer.
Beta Was this translation helpful? Give feedback.
All reactions