<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I'm not going to quote/reply the whole message (with one exception)
because I think we're on the same page on some things (apt/yum is
great and not going away), and on different pages on others (apt/yum
is all we need). I don't think either of us is prepared to budge, so
arguing specifics of chromium, versions, and distro-pacakgers is
moot.<br>
<br>
That said, I'd like to just clarify what I think the goal is, using
android as a model -- since it's pretty similar I think, and we're
hopefully familiar with it now.<br>
<br>
Getting apps on android: google-play, fdroid, whatever. All use the
same apk packages, and those packages work on any android phone or
tablet, whether it's a samsung note running touchwizified android
2.3 or a nexus 10 running stock 4.4. When there's an update, you
don't have to wait for the next version of Android, or for a
community packager. You get updates straight from the developer,
through whatever channel you used to install it.<br>
<br>
When you install an app, you're getting the *current* version, *from
the developers*. It tells you what permissions it needs. It's
restricted to those permissions. There is functionality to
individually allow/deny access levels, but for some reason isn't
exposed on android. You can try out new apps from new developers on
the day they're shipped if so desired. Their package can't
accidentally have an `rm -rf / tmp/myfiles` in a post-install
script.<br>
<br>
Add the systemd-managed linux-namespaces, you could limit filesystem
access, cap cpu usage, etc.<br>
<br>
So I don't see this as a project to replace deb or rpm. I'd go as
far as saying you probably *can't* run a distro with only software
packaged in it's own isolated namespaces like that. And even if
upstreams started supplying bundles, this isn't creating any *more*
work for distro maintainers who build packages from source anyway.<br>
<br>
But having distro-agnostic bundles sounds great to me for some
software,<br>
<br>
<br>
Note: I've also left in the quote & reply for the one security
issue I see with the containers, since it's also applicable to
android and osx app bundles, and I think is worth discussion if
anybody wants to chime in (I don't have anything else to add on this
topic)<br>
<br>
<blockquote
cite="mid:CA+TuoW3DzCzF2aTvexufmKvYJFz+enLptLSr6UFM+cqzOu3c1w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<div>
The only issue I see, and this is a problem also in
OSX/Windows/Android, is how libraries are handled. If
libraries are part of the bundle, then updates
(particularly security updates) become a pain. If they
aren't, you lose some of the containerization that makes
this such a great win for upstreams. I'm sure further
discussion will follow.<span class=""><font
color="#888888"><br>
</font></span></div>
</blockquote>
<br clear="all">
</div>
<div class="gmail_extra">If you install everything from the
official repo, you never see library dependency or version
conflict. That has been my experience running Ubuntu on the
desktop and on servers for many years. The odd exception here
and there (local compile, or vendor repo) also mostly work.<br>
</div>
</div>
</blockquote>
<br>
The concern I have wasn't concerned about missing dependancies or
version conflicts.<br>
<br>
I was concerned with appabc bundling libxyz. When appabc+1 comes
out, the bundle gets updated. When libxyz+1 comes out, that
container would need to be updated also, even though the developer
might not notice (everybody reads CVEs, right?). In the distro
packages, the opposite would happen: libxyz would be updated
(because security is rightfully important), but appabc will likely
have to wait for the next major distro update. If you ask users
whether they want a appabc or new libxyz, they'll say appabc. If
libxyz is something like openssl, and it hits mainstream news, then
users *might* care (even then it's not a given).<br>
<pre class="moz-signature" cols="72">--
Chris Irwin
e: <a class="moz-txt-link-rfc2396E" href="mailto:chris@chrisirwin.ca"><chris@chrisirwin.ca></a>
w: <a class="moz-txt-link-freetext" href="http://chrisirwin.ca">http://chrisirwin.ca</a>
</pre>
</body>
</html>