Inter-WG coordination: Stable application runtimes

Alexander Boström abo at root.snowtree.se
Fri Jan 10 15:32:18 UTC 2014


tor 2014-01-09 klockan 20:30 -0800 skrev Andrew Lutomirski:

> It would be nice, at least, if there was a clean way for these stacks
> to be tracked and, if needed, uninstalled.  Some of these things
> install into /usr, which is a giant mess.  (Pip, the one I use the
> most, doesn't do that IIRC, but it's still annoying that, if I install
> a package with pip, that package *automatically*, *without prompting*,
> and (I think) without verifying signatures or any sort, will pull in
> dependencies from pypi that could be satisfied by yum.  If I then
> install the yum version, I end up in a weird state.

There are systems like virtualenv (python) and local::env (perl) that
mirror the base distro in a separate directory and then let the user
install modules and apps on top, without touching the distro-controlled
directories. This is in my opinion the only sane way to use pip and
CPAN, but in can be improved:

What happens if you add/remove/update a distro package after creating a
virtualenv? Add and update might be ok, but remove will quite likely
break the app.

What about apps that use more than one stack? Can a unified tool that
mirror the whole distro be created? It might be as simple as combining
the existing tools for each stack.

Sane defaults for directories: I've found that when using virtualenv to
install a web app, SELinux will complain less if you put the base
directory somewhere in /var/www. What is the right place to put these
stacks? Codify this in the packaging and in SELinux so that it just
works.

> I'd like some way (maybe using something like mock) to manage these
> things in a somewhat sandboxed way.  Docker is trying to do this, but
> I think it's the wrong approach for a lot of use cases, and its
> nowhere near ready for prime time.

But once you've considered every aspect (for example my points above),
you've basically reinvented Docker anyway.

/Alexander




More information about the devel mailing list