On Tue, Jan 28, 2014 at 07:04:52PM +0100, drago01 wrote: > This is again "hand wavy"(sorry for overusing this term). I can > already have multiple language stacks > for instance python, java, ruby and php on fedora (or pretty much any > other distribution) just fine today. > And I don't expect it to break when the "base layer" (whatever that > means ... kernel? glibc? systemd?) changes. Everything that isn't the language runtime, basically. I'm answering this second question first, because it helps answer the first part. Right now, the version of Python installed has to be the version that is required for code in the base -- yum or dnf at the very least, possibly puppet or chef, maybe firewalld or cloud-init. If your code isn't Python3-ready when Fedora switches, what will you do? If you don't update, your code *will* break. It is often the case that upstream code is tightly tied to particular versions of the language or language modules. That's the hard problem. And what about language modules which aren't yet packaged? Should everyone who wants to use Fedora to deploy their application have to go through creating RPMs for each? The situation is particularly bad with Ruby. We don't have popular system lifetime management software Foreman (http://theforeman.org/) packaged in Fedora because of dependency hell. (And that just got worse when we went to Ruby 4.) Now, we can say "well, Ruby sucks", but.... that's the basic problem. To some degree, the answer might be to just give the user the minimum plus the upstream package management tool (pip or gem or whatever), but to me that seems like giving up on our broad mission. We can do better. SCLs are one attempt at this, and despite some issues seem to be fairly well received. (See for example http://developerweek.com/awards/) There are probably even better solutions out there. One thing I'm interested in experimenting with is Docker images built with packages from SCLs, but rebuilt so that the binary RPMS aren't SCL-enabled (and therefore put ruby at /usr/bin/ruby regardless of the version). Another idea is to work with the upstream packaging system so that when you gem install, an rpm is actually transparently built locally from the rubygems.org packages. There are certainly more ideas -- the Environments and Stacks Working Group is working on this. But there's also a lot of handwaving. :) -- Matthew Miller -- Fedora Project -- <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
