FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-10-2010, 11:06 AM
Steven I Usdansky
 
Default Adventurous yet Safety-Minded

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 broken package set that worked for me, and install. If yum could be persuaded to stash the required deltas locally, and downgrade using those local deltas upon request, I'd be a very happy camper.




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 11:24 AM
Mathieu Bridon
 
Default Adventurous yet Safety-Minded

On Wed, Mar 10, 2010 at 13:06, Steven I Usdansky
<usdanskys@rocketmail.com> 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 to head over to koji, grab the last version of the broken package set that worked for me, and install. If yum could be persuaded to stash the required deltas locally, and downgrade using those local deltas upon request, I'd be a very happy camper.

$ yum history
...
look at the transaction id you want to undo
...

$ yum history undo <id>


However, that's not a proper solution:
- yum will show the update again next time it is run
- yum might be broken due to the update you are trying to revert
- the package is in the repos, so people installing it (not updating
to it) can't revert

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?


----------
Mathieu Bridon
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 11:52 AM
Al Dunsmuir
 
Default Adventurous yet Safety-Minded

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 older version of the package is not a
frequent event, having only the main repository house the necessary
delta files might work out well.

The additional network load for reversions should be containable at
the master. It has a number of advantages in that additional
information about package reversions can be collected:
- Basic statistics about the original and reverted package versions.
- Require that the user be prompted for a reason for the reversion, and
even more valuable information is collected.

Al

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 11:52 AM
Rahul Sundaram
 
Default Adventurous yet Safety-Minded

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 to head over to koji, grab the last version of the broken package set that worked for me, and install. If yum could be persuaded to stash the required deltas locally, and downgrade using those local deltas upon request, I'd be a very happy camper.
>

One feature which can help

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 11:52 AM
Rahul Sundaram
 
Default Adventurous yet Safety-Minded

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 to head over to koji, grab the last version of the broken package set that worked for me, and install. If yum could be persuaded to stash the required deltas locally, and downgrade using those local deltas upon request, I'd be a very happy camper.
>

One feature which can help

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 11:54 AM
Alexander Kahl
 
Default Adventurous yet Safety-Minded

-----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 package systems as each change
on a package (install, update, remove etc.) changes the state of the
system as a whole, i.e. the system relies on side effects (mostly
writing files into shared/global locations) and provides no referential
transparency for such actions, same output for same input is never
guaranteed.
Even if you do provide something like rollbacks for yum you'll never
really return to the original system state so at some point something
will break irrevocably.

A real solution for a healthy life on the bleeding edge and the
side-effect problem would be to dump the global state paradigm and thus
RPM and yum altogether and adopt a system like Nix (http://nixos.org/).

- --
Alexander Kahl
GNU/Linux Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuXlnQACgkQVTRddCFHw109HwCeJs6qiWoGIp QSXY6qNMq0UnjQ
uz0AoLLS/bToEgxsrjNrXwd8tHYEgeAe
=p8jG
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 03:16 PM
"Richard W.M. Jones"
 
Default Adventurous yet Safety-Minded

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-optimal solution is to head over to koji,
> grab the last version of the broken package set that worked for me,
> and install. If yum could be persuaded to stash the required deltas
> locally, and downgrade using those local deltas upon request, I'd be
> a very happy camper.

Yum has a 'yum downgrade' subcommand for quite a while now.

Not sure if the yum cache stashes the older copies though.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 05:13 PM
Bruno Wolff III
 
Default Adventurous yet Safety-Minded

On Wed, Mar 10, 2010 at 04:06:58 -0800,
Steven I Usdansky <usdanskys@rocketmail.com> 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 to head over to koji, grab the last version of the broken package set that worked for me, and install. If yum could be persuaded to stash the required deltas locally, and downgrade using those local deltas upon request, I'd be a very happy camper.

While working on making it easier to recover from brokenness is useful, it
doesn't replace not pushing broken stuff out to users in the first place.
So it shouldn't be 'instead'.

The probablem with broken updates is that people aren't always in a position
to spend time recovering from broken updates at the time updates are applied.
And deferring updates to such a time isn't always a good alternative since
you need to worry about security updates which should be applied promptly.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 06:26 PM
Steven I Usdansky
 
Default Adventurous yet Safety-Minded

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 typically a Rawhide
problem.


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.




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 06:19 AM
Alexander Kahl
 
Default Adventurous yet Safety-Minded

-----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 rollbacks"

- --
Alexander Kahl
GNU/Linux Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuYmY0ACgkQVTRddCFHw12vggCg1mfBxF5LB9 Dg7zB6zl6XJlXZ
GqMAn3DyYhZ4TIzsnUcmTPOIONlMwa51
=lngo
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org