On Tue, Jan 28, 2014 at 10:00:25PM +0100, drago01 wrote:
> Right now, the version of Python installed has to be the version
> 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
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
> 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
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
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>