More > JRiver Media Center 28 for Linux
installJRMC - MC installer for Linux
BryanC:
I just released v1.0b7. This is a major rewrite that should bring installJRMC a lot closer to a 1.0 milestone. There are too many changes to list here, if there was something broken before it should hopefully be fixed, but let me know if not. Note that there are some changes in syntax, --install rpm will still work but has been superseded by --install local. This enables local "rebuilding" of deb files, allowing --compat to work for deb-based distros too!
I also enabled boutique distro support for all DEB and RPM-based distributions so I'm considering this an (almost) universal installer at this point. No Arch or Gentoo support, but if anyone wants to help I can add those too.
The major limitation to running modern MC on older distros is still the glibc/libc6 version for ABI compatability. I haven't gone back to older MC versions to perform package translations for deprecated dependencies, so if anyone is trying to install an old MC version for ABI compatibility and is running into errors, just share the relevant output (with --debug) and I will add a translation.
Awesome Donkey:
Installing MC on Arch is actually pretty simple by using a PKGBUILD, which this one can be found on the AUR (then modified for the user's needs). How this works specifically is with each new MC build the SHA256 hash needs to be updated. The only problem with the package currently on the AUR is, it's a "generic" jriver-media-center package, but I've always thought it should be split for each major version of MC due to how licensing and upgrades work, it doesn't really make sense to me to have a single package that rolls from one new major release to another. *shrugs* But I digress...
Here's the PKGBUILD: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=jriver-media-center
One thing you could do for Arch is to basically follow the PKGBUILD there, but update/improve it and name it jriver-media-center28. Because the jriver-media-center28 package doesn't currently exist, the pacman package manager (and any AUR helper you're using) will complain about it. So in that case what I'd also recommend is having the script update /etc/pacman.conf and add jriver-media-center28 to the IgnorePkg list. That way with each new MC update the script can check for a newer MC, generate a new PKGBUILD for that new build and calculate the SHA256(s), then build the package. And your package manager won't complain about it not existing on the AUR! And it can even install the package too.
If desired you could even create your own user repository for MC and use that for packages and updates, this explains how it works: https://www.sainnhe.dev/post/create-personal-arch-linux-package-repository/
Or the alternative is to use a local repository which is documented here: https://wiki.archlinux.org/title/Pacman/Tips_and_tricks#Custom_local_repository
TL;DR, one of the easier ways to do it:
1) Check the latest version of Media Center and if a new build is available generate a PKGBUILD for the latest version of Media Center.
2) Name the package for the latest MC major version, e.g. jriver-media-center28 then add that package to IgnorePkg section of /etc/pacman.conf, e.g. IgnorePkg = jriver-media-center28
3) Build the package using the makepkg -s command. You can also build and install the package via makepkg -si.
4) Install the package either via sudo pacman -U <path to package> or by using makepkg -si as mentioned above.
BryanC:
OK, I'll take a look at adding Arch support in my next stretch of spare time.
BryanC:
--- Quote from: Awesome Donkey on January 14, 2022, 01:24:24 pm ---One thing you could do for Arch is to basically follow the PKGBUILD there, but update/improve it and name it jriver-media-center28. Because the jriver-media-center28 package doesn't currently exist, the pacman package manager (and any AUR helper you're using) will complain about it. So in that case what I'd also recommend is having the script update /etc/pacman.conf and add jriver-media-center28 to the IgnorePkg list. That way with each new MC update the script can check for a newer MC, generate a new PKGBUILD for that new build and calculate the SHA256(s), then build the package. And your package manager won't complain about it not existing on the AUR! And it can even install the package too.
TL;DR, one of the easier ways to do it:
1) Check the latest version of Media Center and if a new build is available generate a PKGBUILD for the latest version of Media Center.
2) Name the package for the latest MC major version, e.g. jriver-media-center28 then add that package to IgnorePkg section of /etc/pacman.conf, e.g. IgnorePkg = jriver-media-center28
3) Build the package using the makepkg -s command. You can also build and install the package via makepkg -si.
4) Install the package either via sudo pacman -U <path to package> or by using makepkg -si as mentioned above.
--- End quote ---
I've got a few questions and comments before I dive in:
* Which type of firewall do most Arch users typically use? I can use nftables but the firewall managers are nicer to interact with. I see that Arch recommends firewall-cmd yet it's not pre-installed.
* Re; package naming convention. I do understand the maintainer's reasoning behind making the jriver-media-center package essentially a "rolling" installation. It makes it easier to manage (no manual versioning required) and users can always install a specific version if they choose to (and add an exclusion to their package manager to peg it). I treat MC as a subscription service at this point, but I do understand your point re: licensing and major versions. installJRMC currently installs a "rolling" package name "MediaCenter" on rpm-based distros and uses your preferred (and the default method) of per-version package names on deb-based distros. I would like for these to be consistent in the future but rolling makes upgrades more seamless for my clients as I tend to run beta builds, although I'm not hard set on this.
Awesome Donkey:
1. Typically a firewall isn't activated and used unless the user wants it (none of my Arch installs have a firewall running), and usually then it's either something using nftables or iptables.
2. Fair enough, but personally I'd probably still manually keep the package name with the version number.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version