RFC: Fedora revamp proposal

[seth vidal]

On Tue, 05 Mar 2013 13:07:59 -0500
Colin Walters <walters at verbum.org> wrote:

> On Tue, 2013-03-05 at 12:44 -0500, Stephen Gallagher wrote:
> 
> > Well, in that case I suppose we'd need to add a new tag-set,
> > something like rawhide-pending 
> 
> In other words, another layer.
> 
> I'll only repeat this maybe every 6 months or yearly, depending on how
> annoying people find me.  But basically, the #1 problem is the
> inability of RPM to go backwards (i.e. versions must always go up).
> 
> It's like a car with no brakes and no reverse gear, driving down a
> road that's being dynamically built in front of it.
> 
> A lot of times, the correct response to "stuff just broke!" is
> "revert". Not just revert - revert *quickly*. Don't let the master
> tree be broken. Don't go off a cliff just because someone put a wrong
> sign on the road.
> 
> For example, let's say a new version of Mesa breaks GNOME with
> llvmpipe. One really can't fault the Mesa maintainers, because it's
> quite possible they tested it, just on the Intel or AMD hardware on
> their laptop.
> 
> But the correct response here is still to revert to the previous Mesa
> until the problem is found and fixed.
> 
> If instead what we have is another "layer"/"repo" or state of
> packages, this issue would end up blocking progress on *everything
> else* into rawhide until it was fixed, because the AutoQA tests would
> just keep failing. That's very problematic.
> 
> (This is assuming the AutoQA tests are something interesting and
> useful like booting GNOME, and not spelling checks for the spec file
> descriptions or something)
> 
> But given the drastic changes to RPM (and all the software built on
> top of it like mock, koji, createrepo, etc.), that would be required
> to fix this "newer is always better" problem, I can't fault you for
> saying we should add another layer.
> 
> 



If the issue was only 'newer is better' then rpm can easily get around
it. Hell, so can yum, now.

The issue is that we have nothing that even resembles a backward-compat
process for user DATA.

I can roll back package binaries all day long, but if there is a
db or config format which has moved on - and been modified -the user is
screwed.

For fun - try to run a desktop of f16 and f18 using a shared homedir
sometime.


So - I don't see how adding another layer is really a problem - since
the 'infinite versions in every direction' won't help our users losing
their configs or worse their data.

am I missing something here? Have we solved the user data problem?

-sv