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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
