Fedora.next in 2014 -- Big Picture and Themes

drago01 drago01 at gmail.com
Tue Jan 28 21:00:25 UTC 2014

On Tue, Jan 28, 2014 at 9:06 PM, Matthew Miller
<mattdm at 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".

More information about the devel mailing list