Re: Fedora.next in 2014 -- Big Picture and Themes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 28, 2014 at 9:06 PM, Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx> 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".
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux