On Tue, 05 Mar 2013 13:07:59 -0500 Colin Walters <walters@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
