Rich Freeman via plug on 20 May 2020 11:06:38 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [PLUG] One app, one directory, no install/uninstall... |
On Wed, May 20, 2020 at 1:27 PM JP Vossen via plug <plug@lists.phillylinux.org> wrote: > > On 5/18/20 7:13 PM, Fred Stluka via plug wrote: > ... > > The only real need for an install program is to share single > > copies of library files and such, right? Seems like there ought > > to be a better way.... > > You know you just described "Snaps" (Ubuntu, [1]) and "Flatpack," [2] > right? Sort of. Those do containerize applications, but I believe they also bundle libraries and such (except maybe for anything that is part of the base distro). NixOS has a model that can have shared libraries but also having a "one application per directory" sort-of model. Basically every package installs into its own little root, and packages can be linked across these. The gotcha here is that the linking is still version-specific, so if you update libz on your system you'll end up with two copies of it, and until all the reverse deps are updated they'll still be linked to the old version, and thus have any security vulnerabilities associated with it. There really is no perfect solution here. If you make all the applications self-contained then their libraries will consume extra RAM and you have all the security issues of static linking. If you let the applications just dip into the library directory and match on SONAME then you have problems with some brain-dead upstream doesn't understand how to properly use SONAMEs. Forking a common library and then deleting half of its exports while keeping the same SONAME for "compatibility" seems to be in fashion these days. If you can trust updates to be timely across everything you have installed then containerizing things or statically linking them isn't as much of a problem, but you're trusting that when zlib has a problem every single reverse dep is getting updated, which means whoever does the packaging has to be really on top of what is getting bundled where. -- Rich -- Rich ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug