On Fri, 2010-03-12 at 17:04 -0500, Chris Ball wrote:
>> But (and I mean this with no disrespect to anyone else) I am not
>> going to want to use it seriously when it means rolling back
>> everything that changed since installing updates (sure, if the
>> update is a kernel update an
Hi,
>> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
> That might be very useful for OLPC users, etc.
(Just to be clear, my interest in writing up this feature proposal was
unrelated to my work for OLPC; the proposal is purely aimed at Fedora,
and we don't have any plans t
On Wed, 2010-03-10 at 18:22 +0530, Rahul Sundaram wrote:
> On 03/10/2010 05:36 PM, Steven I Usdansky wrote:
> > Instead of worrying about the occasional brokenness caused by an update to
> > a stable release, how about focusing on a mechanism to easily recover from
> > it? As long as the update h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2010 11:54 PM, Kevin Kofler wrote:
> Alexander Kahl wrote:
>> Please define "massive" if you're keeping exactly what's needed to keep
>> everything running and prune anything else by using a sophisticated,
>> tunable garbage collection mechani
Alexander Kahl wrote:
> Please define "massive" if you're keeping exactly what's needed to keep
> everything running and prune anything else by using a sophisticated,
> tunable garbage collection mechanism.
The whole point of the exercise was to do a lot of updates. But the more
updates we do, th
On 03/10/2010 07:54 AM, Alexander Kahl wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/10/2010 01:06 PM, Steven I Usdansky wrote:
>> Instead of worrying about the occasional brokenness caused by an update to a
>> stable release, how about focusing on a mechanism to easily recove
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2010 03:05 PM, Tomas Mraz wrote:
> On Thu, 2010-03-11 at 11:53 +0100, Alexander Kahl wrote:
>> Oh, and by the way, we could leave behind all those discussions
>> regarding dynamic linking: RPATH for everything and everyone. If you've
>> linked
On Thu, Mar 11, 2010 at 11:53:18 +0100,
Alexander Kahl wrote:
>
> There are of course cases where package maintainer work and QA can
> improve rollback quality:
I got burned a while back by a Sunbird change (maybe in a library it
uses) that broke access to my local calendar data. I was not a h
On Thu, 2010-03-11 at 11:53 +0100, Alexander Kahl wrote:
> Most of what is described here is already covered by Nix (leaving out
> the hardware driver part).
>
> This is why I endorse dumping yum, RPM *and* the stupid FHS in favor of
> Nix, focusing all development on something that is clearly su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2010 02:16 PM, Kevin Kofler wrote:
> Alexander Kahl wrote:
>
>> On 03/10/2010 08:26 PM, Steven I Usdansky wrote:
>>> If there's a magic solution that will satisfy the vast majority
>>> of Fedora users, I have absolutely no clue as to what it
Alexander Kahl wrote:
> On 03/10/2010 08:26 PM, Steven I Usdansky wrote:
>> If there's a magic solution that will satisfy the vast majority
>> of Fedora users, I have absolutely no clue as to what it might be.
>
> Please read: http://nixos.org/nix/
> Esp. "Atomic upgrades and rollbacks"
That's n
On Thu, Mar 11, 2010 at 11:53 AM, Alexander Kahl wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/11/2010 09:24 AM, yersinia wrote:
> > On Wed, Mar 10, 2010 at 1:54 PM, Alexander Kahl wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 03/10/2010 01:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2010 09:24 AM, yersinia wrote:
> On Wed, Mar 10, 2010 at 1:54 PM, Alexander Kahl wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 03/10/2010 01:06 PM, Steven I Usdansky wrote:
>> There is no real recovery for traditional
On Wed, Mar 10, 2010 at 1:54 PM, Alexander Kahl wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/10/2010 01:06 PM, Steven I Usdansky wrote:
> There is no real recovery for traditional package systems as each change
> on a package (install, update, remove etc.) changes the state
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2010 08:26 PM, Steven I Usdansky wrote:
> If there's a magic solution that will satisfy the vast majority
> of Fedora users, I have absolutely no clue as to what it might be.
Please read: http://nixos.org/nix/
Esp. "Atomic upgrades and rollba
I realize this doesn't address the concern about not pushing broken
updates to begin with. However, if yum and/or rpm could do a
downgrade from locally cached delta, it would make reverting the
change that broke the system much easier. This obviously won't
work if it's rpm that breaks, but that is
On Wed, Mar 10, 2010 at 04:06:58 -0800,
Steven I Usdansky wrote:
> Instead of worrying about the occasional brokenness caused by an update to a
> stable release, how about focusing on a mechanism to easily recover from it?
> As long as the update hasn't corrupted any critical files, my non-opt
On Wed, Mar 10, 2010 at 04:06:58AM -0800, Steven I Usdansky wrote:
> Instead of worrying about the occasional brokenness caused by an
> update to a stable release, how about focusing on a mechanism to
> easily recover from it? As long as the update hasn't corrupted any
> critical files, my non-opti
On 03/10/2010 05:36 PM, Steven I Usdansky wrote:
> Instead of worrying about the occasional brokenness caused by an update to a
> stable release, how about focusing on a mechanism to easily recover from it?
> As long as the update hasn't corrupted any critical files, my non-optimal
> solution is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2010 01:06 PM, Steven I Usdansky wrote:
> Instead of worrying about the occasional brokenness caused by an update to a
> stable release, how about focusing on a mechanism to easily recover from it?
There is no real recovery for traditional
On Wednesday, March 10, 2010, 7:24:18 AM, Mathieu Bridon wrote:
> On Wed, Mar 10, 2010 at 13:06, Steven I Usdansky
> Your proposal especially doesn't address the third point. How do
> effectively you rollback the package on the mirrors when you don't
> control them?
Assuming reversion to an o
On Wed, Mar 10, 2010 at 13:06, Steven I Usdansky
wrote:
> Instead of worrying about the occasional brokenness caused by an update to a
> stable release, how about focusing on a mechanism to easily recover from it?
> As long as the update hasn't corrupted any critical files, my non-optimal
> sol
Instead of worrying about the occasional brokenness caused by an update to a
stable release, how about focusing on a mechanism to easily recover from it? As
long as the update hasn't corrupted any critical files, my non-optimal solution
is to head over to koji, grab the last version of the broke
23 matches
Mail list logo
