On Tue, Jan 28, 2014 at 9:06 PM, Matthew Miller <mat...@fedoraproject.org> wrote: > 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.
Isn't that a contradiction to what you said above "everything that isn't a language runtime" and now you are talking about python updates. OK in that case sure if you update the language runtime itself to a version that is not compatible with the deployed applications you have a problem. But the "base" itself has nothing to do with it (ignoring some odd fringe cases). > 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? Yeah I agree that this part needs fixing. Maybe automated packing helps. We are to much focused on packing and packages while a lot of that could be automated. You may not get the "cleanest" spec files that way but there was some distro created by Arjan I think that does it this way. > 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. Yeah SCLs are a way to deal with this issue. But is it really incompatible with how we did Fedora in the past? Don't get me wrong I am not trying to "stop" Fedora.next I am just trying to understand what toughs lead to it. It looks like "ok there are problems lets do stuff differently and see how it works out". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
