Inter-WG coordination: Stable application runtimes

Adam Williamson awilliam at redhat.com
Fri Jan 10 03:58:44 UTC 2014


On Fri, 2013-12-20 at 00:03 +0100, Kevin Kofler wrote:
> J├│hann B. Gu├░mundsson wrote:
> > In case of 3 you would never update an container you would replace it
> > with a new container ( or App image rather ) which contains the
> > update/upgrade and delete the old container or in case of Gnome with a
> > new "App image" If I understood Alexander correctly at that BOF at guadec.
> > 
> > Personally I think we should entirely drop any notion of implementing
> > software collection in Fedora on rpm bases ( could be implemented as
> > standalone app image ) since we dont need it RHEL does [1] and go
> > directly looking at implementing Alexander's proposal regarding app
> > images.
> 
> Argh, no thanks! "App images" are even worse than SCLs. They are a security 
> nightmare, an immense waste of disk space and RAM, and just generally a 
> totally broken concept. Applications need to stop thinking they are a 
> distribution! Such applications-that-think-they're-distros are a horrible 
> mess to deal with, and generally the only sane way to handle them is to 
> untangle that distro-in-a-distro mess and package them as normal 
> applications. (See e.g. what we have done to SAGE(Math) to package it for 
> Fedora. Now it is a sane package using system versions of its dependencies 
> rather than a huge multi-hundred-MiB tarball bundling even things like 
> Python and Maxima!)

Coming to this discussion late, but I do think it's an interesting one.

There's a deep question lurking behind the scenes here, which is: what
is the distro's responsibility, exactly?

People are already deploying static bundled stacks on Fedora. There are
large ecosystems where this has become the norm: Javaland, PHPland,
Rubyland. A lot of people don't deploy their Java or PHP or Ruby apps
from their distribution's repositories, they use an overlaid
distribution mechanism of some kind which promotes the use of bundled
dependencies to provide a 'stable' stack.

You may think they're wrong, I may think they're wrong, but they're
doing it. It is very very difficult to 'convert' these entire ecosystems
into sets of packages that obey the traditional policies of Linux
distributions regarding bundling; in practice it's probably impossible
to do so in a way that people actually involved in those ecosystems are
happy with, which is why they bypass distro mechanisms. We don't have
anywhere near a full Ruby or PHP or Java ecosystem packaged for Fedora,
and the packages we do have are frequently broken or outdated, precisely
because of this major mismatch between how we do things and how those
ecosystems do things.

So the question becomes, what is it appropriate for a distribution to do
in this situation? My personal opinion is that what's appropriate for a
distribution to do is also, happily, what's easiest for a distribution
to do: punt on it. Entirely punt on the whole thing.

There are already multiple mechanisms for the deployment of bundled
software stacks, many associated with a given ecosystem - Composer for
PHPland, npm for NodeJSland, bundler for Rubyland, etc etc. We've seen
that GNOMEland is apparently looking down a similar path for deploying
'app bundles', and will no doubt come up with its own mechanism.

I doubt a distribution can come up with a Single Bundled Stack
Deployment Mechanism To Rule Them All, or something like that, and it is
a layering violation for this kind of mechanism to be owned by a
distribution: they should be - and in practice *are* - owned by their
ecosystems.

I'm coming to the conclusion that at some point distros have to give up
swimming against the tide and just say, look, if this is the way this
ecosystem wants to go, then it's your problem. Fedora's job for such
ecosystems would simply be to make sure their distribution mechanism
works on top of Fedora - if it's one we care about - and then butt out.
I'm not sure we're achieving anything practical for anyone by bending
PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform
to Fedora's packaging guidelines (often at the cost that we have to turn
stuff off, or break stuff, or be months or years behind upstream, or be
massively incomplete), and I say this as someone who's spent the last
couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to
achieve precisely that.

Distros can work with ecosystems - like the roughly defined 'basic *nix
userland' ecosystem - which are written in C and C++ and Bash and Python
and Perl, and where libraries understand the value of well-defined and
widely observed policies regarding API/ABI stability and library
versioning and so on. I suspect the only way distros can really 'work'
with ecosystems that don't do so is to stop trying and leave them to it.

So to bring it to the context of Fedora.next - if some of the
'Fedora.next' products want to have the capability to deploy 'stable',
i.e. bundled, stacks, then I think they should be 'allowed' to do so (in
the sense that we can't really stop them), but the mechanisms used to do
so should not be considered a part of the Fedora project, they should be
upstream projects that are deployed on top of Fedora.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the devel mailing list