On Tue, Jan 28, 2014 at 10:00:25PM +0100, drago01 wrote: > > 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. That's an example where the language is very tightly tied into the base. But it's the case in general that all language environments we ship are tied to the set of packages we ship at that time. Occasionally we do compatibility packaging (python3 is actually an example of this), but in general it's pretty painful. This is kind of creaky -- I'll use Puppet as an example: we shipped it largely broken for several releases, because we updated Ruby to a version not supported upstream. And we probably also shipped code that required at least that new version. How do we decide in situations like this? The traditional Fedora approach is to error in favor of going forward. Because "first" is part of Fedora's fundamentals, I don't think we should stop that, but we also could find a way to accommodate. (And that's an example of something _within_ the distribution -- there's no concern at all for user code.) > > 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. Yeah, so I think we're on the same page here. > Yeah SCLs are a way to deal with this issue. But is it really > incompatible with how we did Fedora in the past? Traditionally, yes, although there's been some heroic guideline-writing recently. > 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". I hope we are and can be more intentional than that. Conversations like this one help! -- 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
