Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 8295] atomic dispel/install operation

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 8295] atomic dispel/install operation
  • Date: Tue, 22 Feb 2005 10:08:12 -0800 (PST)

http://bugs.sourcemage.org/show_bug.cgi?id=8295





------- Additional Comments From seth AT tautology.org 2005-02-22 10:08 -------
We could blacklist glibc by setting CONSISTENT_UPGRADE=off in it. Have the
feature default to off at first and create a menu item in the FEATURES menu
for it.

I thought of this because gentoo claims to have so-called "safe emerges", but
they really don't have safe emerging -- I consider it unsafe. They preinstall
to a separate location and then merge over the top of the old install on the
real install (and do some finagling to delete stuff not in the new set of
files), but while it is atomic at the file-level, it's not atomic at the
entire-package level, that could lead to some interesting race conditions. I
think the way sorcery does it is currently safer, dispel the whole spell and
install it separately (actually, in db theory ACID, this would be
"consistency",
not atomic *changes the subject line*). The filesystem can't ensure atomicity
unless we used a filesystem driver that can bind a filesystem overlay (which I
believe is supported in a certain strange linux distro that wrote their own
driver to do filesystem overlays to make package management easier at the cost
of a performance hit). If CONSISTENT_UPGRADE is on and there is no tarball
archive for the old version already, we could on dispel make a temporary
tarball
from the old install log before we rm everything.

Just trying to think of ways to beat gentoo at their own claimed features, but
in a better way.

About the temporary root idea, that's just the way gentoo does it -- we could
of
course do that, except dispel first then install in a "non-file-atomic" way to
avoid the race condition problem (no behavior is better than unexpected
behavior). Since we have INSTALL_ROOT, I suppose we could move over to the
tmp
root fairly easily for basesystem stuff -- I would worry about old spells that
have no sense of INSTALL_ROOT.

--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




Archive powered by MHonArc 2.6.24.

Top of Page