Fedora.next in 2014 -- Big Picture and Themes
mattdm at fedoraproject.org
Tue Jan 28 21:17:09 UTC 2014
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
> 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 at fedoraproject.org>
More information about the devel