Inter-WG coordination: Stable application runtimes
luto at mit.edu
Fri Jan 10 04:30:25 UTC 2014
On Thu, Jan 9, 2014 at 7:58 PM, Adam Williamson <awilliam at redhat.com> wrote:
> 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  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
> 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.
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.
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.
More information about the devel