On Tue, Sep 15, 2015 at 11:08 AM, Chris Adams <linux@cmadams.net> wrote:
Once upon a time, Matthew Miller <mattdm@fedoraproject.org> said:
> A. Things that I care about keeping up to date are always moving too
>    slowly.
>
> B. Things that I care about keeping stable are always moving too quickly.
>
> C. Things that I don't care about shouldn't bother me by having bugs,
>    security holes, changes in interface or functionality, or security
>    updates.
>
> D. And, for every value of "I", each set of _things_ is unique.

Shoot, not just for every value of "I", for every combination of "I" and
"this system".  I have RHEL/CentOS systems where customer X wants new
PHP but old MySQL, and customer Y wants stable PHP but new MariaDB.

--
Chris Adams <linux@cmadams.net>

The only real "solution" to this, to the extent that there is one, is better support to have multiple versions of at least some things install-able either in parallel or at least, if not in parallel than being able to choose between version X and version Y of at least some software.

I realize this isn't a terribly realistic solution (among other things, we don't have the manpower to make it happen). But still:

For Python, for instance, we currently support this. (So does basically everyone else). You can have Python 2.x and/or Python 3.x installed at the same time.

We don't support this for Java runtimes; there was a discussion a while back about this. If I am stuck on Java 1.7 for some reason-- for example, if I'm doing Android development, which at least last I checked (a month or two ago) *still* only supports Java 1.6 and 1.7-- I cannot get either through Fedora's official repos because we have 1.8 now (which is a good thing, it's definitely good that we ship the latest version of Java). In this particular instance, I can install Java 1.7 out of a copr and it works. But is that true for versions of other languages and stacks? I'm not sure. I suspect Python is something of a special case, though I could be completely wrong about that.

Also, we have never really supported this sort of thing for, say, desktop environments. Or, rather, we now have MATE + GNOME available but when GNOME 3 was first released, MATE didn't exist so GNOME 2 wasn't kept around. (I really do not want to derail this thread into an argument about desktop environments, but it's sort of the extreme edge case of what I'm talking about).

Now, like I said, we don't have the manpower to support multiple versions of KDE or GNOME ourselves, so I'm not seriously suggesting we do that, or that we should go against our principles of "First", but it's what came to mind as I was reading the discussion.

Ben Rosser