Fedora.next in 2014 -- Big Picture and Themes

[Matthew Miller]

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.

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?

The situation is particularly bad with Ruby. We don't have popular system
lifetime management software Foreman (http://theforeman.org/) packaged in
Fedora because of dependency hell. (And that just got worse when we went to
Ruby 4.) Now, we can say "well, Ruby sucks", but.... that's the basic
problem.

To some degree, the answer might be to just give the user the minimum plus
the upstream package management tool (pip or gem or whatever), but to me
that seems like giving up on our broad mission. We can do better.

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.

But there's also a lot of handwaving. :)



-- 
Matthew Miller    --   Fedora Project    --    <mattdm at fedoraproject.org>