On Thu, Jan 9, 2014 at 7:58 PM, Adam Williamson <awilliam@xxxxxxxxxx> 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 [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. 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. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
