The bundled dependencies, which are linked against all of Plex’s binaries, are found in the ./lib subdirectory.
These include what makes Plex “Plex” so are required. This mechanism is how we are able to have only one external dependency on glibc 2.14.1. Each set of .so files is matched to its distributed version (as reflected in the package file name).
We structured it this way, having set RPATH as we did, so PMS is atomic at the package level.
Removal of the target directory (/usr/lib/plexmediaserver) removes all the binaries.
Removal of the control scipting (/etc/init.d/plexmediaserver and /lib/systemd/system/plexmediaserver.service) complete the uninstallation.
File /etc/default/plexmediaserver, if used, is left in place as it represents the user’s site configuration. We feel it would be rude to remove it plus it would make downgrading binary packages cumbersome by imposing user-required interaction to preserve it.
To share how things are setup in the Debian packaging (soon to be in the RPM packaging as well),
User plex, in group plex is required and created if not present even if overridden by the site configuration. (systemd override or /etc/defaults). User plex is a no-login non-privileged user.
Directory /var/lib/plexmediaserver presence is also required but also may be overridden in the site configuration. (systemd override or /etc/defaults)
preinst gathers all system information and validates it. If installation will not succeed, it reports the error and halts.
Group detection of /dev/dri (to match the kernel) adds user plex to that group to support hardware transcoding.
Detection of systemd, init, docker container , LXC , or a custom environment drives the final installation. (cat /proc/1/comm)
a. Detection of docker means the user has installed the package inside an existing docker environment. No further processing is required.
b. Detection of LXC proceeds as if normal with exception of not invoking udevadm due to the long-standing udevadm bug.
c. All other detected configurations pass through as ‘CUSTOM’.
We structured it this way, having set RPATH as we did, so PMS is atomic at the package level.
This is directly against the packaging policy of all Linux distributions that I’ve ever worked with.
The strong preference is for applications to use the system wide installation of whatever library is depended on, whenever there isn’t a very strong reason not to.
Can you provide some guidance on which of these bundled libraries have been modified by the Plex team, so that linux distributions can better understand where they can insert system libraries in place of the bundled libraries?
I know many proprietary packages which carry no external dependencies beyond glibc.
Yes, there are tons of proprietary packages which do exactly what you say.
Those packages are bundling their third party dependencies despite the packaging guidelines for the Linux distribution they are packaged for saying not to do that.
I’m not telling you to stop doing what you’re doing. I’m asking if you can give the community some more information about which third party dependencies have been patched by Plex. This will allow for Linux distributions that Plex doesn’t offer official support for to determine which of the libraries can be replaced by system-wide versions, and which can’t. E.g. Gentoo considers bundled third party libraries that duplicate system libraries to be a security risk, and pressure is put on Gentoo developers who wish to include packages that do this to, well, not include those packages.
It is not uncommon for containers to bring their own runtime libraries which are themselves duplicates.
While, in a normal chroot environment, this isn’t a problem however running a container in Host networking mode, as a privileged container, represents a security risk.
I’m sorry but this is no longer the appropriate venue for this discussion. It is heading in a direction which it shouldn’t (in public view).
I believe the next best step is to reach out to the Plex product team directly via www.plex.tv (contact form). They, in turn, will include Engineering as necessary.
I’m not a Gentoo developer. I’m simply an end-user (who is a software engineer, for what it’s worth) who wants to use Plex on Gentoo.
I don’t use Docker, but I understand how Docker works.
I don’t understand where you think the discussion is heading that isn’t appropriate for public view. I was just asking a simple question about your third party libraries, and which of them have been patched. You’re clearly one of the experts on how the Plex packages are put together for RPM and Deb based distributions, so I don’t see why you aren’t able to provide an answer in this venue.
I also pointed you to several different distributions’s documentation saying not to do what you’re doing with the Plex RPM / Deb package. But I don’t really care about RPM / Deb based distributions, so shrug.
I believe the next best step is to reach out to the Plex product team directly via www.plex.tv (contact form). They, in turn, will include Engineering as necessary.
No, not going to do that. Instead, I’m going to see what happens to the Gentoo package, and if it doesn’t get fixed to the satisfaction of the Gentoo developers and therefore gets removed from the package tree, I’ll stop giving Plex money.
Another Gentoo + Plex Pass holder here. I am also in the boat of happily supporting Plex and also worried about the choices the Plex team is expressing here.
Simply expressing that I am a paying customer of Plex (as well as preaching its virtues to a number of friends that have also purchased Plex), and would be an unhappy customer to have this removed from the Gentoo overlays due to security / packaging concerns.
While I’m also counted among those who would be hurt by Plex removal from Gentoo Portage - I don’t think we can put any blame on @ChuckPa and the rest of the engineering group.
First of all, whether if you’re a Plex Pass subscriber/lifetimer or just a free tier user - Plex sees you as a customer all the same.
Now the actual main issue here is that Plex is not currently officially supported on Gentoo.
The current package we have on Gentoo is unbeknownst to Plex development group and is done without their blessing, in a manner that doesn’t warrant support from them.
It is totally within their right to insist on the architecture of their own product, and decide whether to adapt it/create a version of it that sits well with Gentoo principals.
We cannot demand Plex to make modifications to their software when they do not acknowledge Gentoo as a viable platform. Therefore I believe the first goal is to get Gentoo recognized as an official Plex platform.
After that is done, I’m sure all the disagreements can be resolved and a compromise can be made.
I will do my part by using the contact form on www.plex.tv and ask for this support - I encourage @jonesmz and others to do the same.
If we’re only a handful of people that request for this, while the majority of Gentoo users reside to the unofficial Plex overlay by comio - then I don’t see this matter resolved very soon. At least not until Python2 is completely removed from Plex.
I’m maintaining the plex-overlay’s ebuilds as my spare time hobby.
Regarding your points:
I removed the python virtualenv support in order to use the already supplied python binaries.
the codecs_kr.so seems to have a wrong RPATH. I just fixed using the same RPATH as provided by others codecs_*.so files.
I moved to package systemd service file, in the past I already did this but I switched back to be aligned with Gentoo’s official ebuild.
I will evaluate to switch to yours sysV init scripts, but I cannot test on my local machine and it’s not my priority for now.
Regarding the /dev/dri access, the ebuild includes the acct-{user,group}/plex dependencies that assign the correct UID and GID adding also the user to “video” and “render” groups. This should be enough to grant the rights to access to /dev/dri device.
Thanks again for your clarifications and best regards,
Just to clarify, since there seems to be some sentiment of hostility in the thread:
I wasn’t accusing anyone of doing anything wrong, and I certainly wasn’t expecting Plex to care about a platform that they don’t officially support. Me pointing out that the Plex package was designed in a way that’s contrary to the packaging guidelines of various Linux distributions wasn’t intended to be hostile. I was just trying to point out the discrepancy.
Regardless, my motivation was simply to ask for some of (not even all of) the information necessary for the Gentoo package to move closer to how Gentoo packaging guidelines say it should be packaged.
I will do my part by using the contact form on www.plex.tv and ask for this support - I encourage @jonesmz and others to do the same.
I mean… we can do that, but what exactly is this going to do? Put an email in some random inbox that’s checked once a month by the person who sits next to or just down the hall from @ChuckPa ?
Plex isn’t some mega corp with 10 thousand employees. If they wanted to care about Gentoo they already would. We don’t represent a large enough userbase for them to order an engineer to pay attention to us. It’s wonderful that @ChuckPa was willing to give us the feedback that was already given, but I can’t imagine we’ll see any action on requests made via the contact form on the website.
Another PlexPass user on Gentoo here.
It is understandable that a python 3 version of plex isn’t ready yet, porting takes time, we see that in multiple applications.
But what I don‘t get, is that there are no plans at all and we are discussing about some „Gentoo decisions“ and „unsupported distributions“, while python2 is end of life since the beginning of 2020, a date that is known since some time at least.
Ubuntu 18.04 came without python2.
Ubuntu 20.04 had python2 removed from main repo.
Even Fedora as a community distribution has ported nearly everything to python3 in between.
python 3.2 (first backwards compatible) is out since a decade now, so people knew they will have to migrate off of python2 for a better half of a decade now…
Regardless of shipping own libraries or what is packed into some application or where it is used, there will be no patches or security fixes for python2 anymore - nowhere.
This poses a security risk and it will always do.
So in my opinion it is a must for every application that uses python to port to python3. And if not done yet, you‘d better catch the train.
What is the plan otherwise?
Stick with python2 until 2030 or python4?
Why not? If you’ve been reading this thread @ChuckPa has explained that the use of python2 in Plex is as an internal component the server ships with, and is only used within Plex Media Server. Having a distro “drop” phython2 does not effect Plex’s ability to run, as it’s not a requirement it be present to install.
It’s like if I ran a business with some ol’ bessy Windows XP box doing accounting in a back office that I only use for that, and it doesn’t get connected to the Internet.
It doesn’t matter if it doesn’t have the latest security patches – it’s air gapped.
It doesn’t matter if it even has antivirus software, we’re not connecting random flash drives to it.
It doesn’t matter if it can’t run the latest and greatest version of a program – it does the job it needs to with what it has already.
Something I have not seen answered yet in this thread:
If Plex is not even officially-supporting Gentoo, why should they let Gentoo’s board dictate the development of their product?
While things may work well as they always have, at some point it’ll be more work maintaining a Python2, than it would be just to have taken the initiative to port things over to Python3 nearly a decade ago.
That being said, for a healthy company future, its usually best to keep with supported dependencies, than it is to try and refuse to upgrade and maintain them yourself. Something I’ll never understand about legacy apps.
I am a Plex pass lifetime user. And also a gentoo user of 20 years.
I also am using an overlay and with the most recent version, suddenly I am unable to use Plex… I’d insert an image of 2 crying kids who can’t watch their cartoons now, but I’ll save you from that.
Server starts fine, listening fine from what I can tell. But neither app nor web interface loads. Even downgrading offers nothing.
Honestly I can clearly see their “Linux” support is clearly part of their “Mac” support being Unix is near identical to Linux with minor changes needed. That part honestly isn’t what annoys me at this exact moment. It’s their incessant reliance on dead technology that put us in this position in the first place.
Right now I’m attempting to find ways of keeping the dead horse rideable.