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