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