On Fri, Jun 17, 2016 at 10:56:28AM -0400, Owen Taylor wrote:
> How would non-GUI applications be installed in this picture?
I'm not entirely sure what you have in mind for a non-GUI applications,
but options available include.
For _services_, running in a docker container seems like a good
solution. I'm more talking about compilers, text editors, and other
various utilities. I use the `calc` command-line calculator all the
time, for example, and taskwarrior for keeping my todo list.
* Run in a container
This is the obvious path for network services - if you want to run
Mailman or Wordpress on your workstation. It's also may be the
an interesting route for development tools - the container
provides the "SDK" you are developing against.
That's an interesting approach. How could we make that easy and
obvious? Possibly we could install desktop icons and tools that start
up a given "SDK" environment -- and let you customize it to your liking
(so _we_ aren't deciding "emacs or vi?" for people). Maybe even the
default terminal app drops you into a utility container rather than the
base system.
* Use a layered RPM
rpm-ostree now has support for locally installing RPMs on top of an
OSTree. We don't want to use it as our primary installation
mechaniss, because it causes problems for the idea that applications
are upgraded independently from the OS. But it can be the perfect
escape hatch if you need 'tracepath' or whatever and it isn't
otherwise available.
maybe this is the way, but unless we put a lot of development into
alternatives, I think it's going to be very common in our target
audiences, so it'd need to be more than a rarely-used "escape hatch".
* Package in a flatpak
There's nothing inherent about Flatpak that prevents it from working
for many TUI and command line tools; the export system would have to
be extended to export a wrapper script to turn 'nano' into
'flatpak run org.nano-editor.Nano'. Turning on sandboxing is harder.
Yeah, this seems possibly useful for some tools, but the sandboxing
seems _really_ hard.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader