Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Drupal (and other) install setup

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Drupal (and other) install setup
  • Date: Wed, 06 Jun 2007 12:53:32 -0700

David Kowis wrote:
<snip>
> Perhaps we could modify the queueing method. Add a
> needs-attended-upgrade flag. Just as an alternative idea. It'd be useful
> for other spells as well as the web application spells, and could be a
> better long term solution. The dev updating the spell should know that
> there are upgrade issues, and so it cannot be done unattendedly. Perhaps
> the default sorcery queue should not include spells marked
> needs-attendance. It would require a bit of modification to sorcery, but
> will solve more problems than just leaving the files around to find
> eventually. And works for more things than just web spells.

I'd rather not add another queuing method to take care of this. Although
I'm biased, I believe my proposal above is the best approach. ;) There
should be only one queue method, otherwise people may "forget" (or never
learn about) this other method and never see the updates. Sometimes too
many options for similar functions become more of a nuisance than a help.

As for leaving the files around to be noticed eventually, if the admin
is using web apps and is aware of this proposed method, he/she may have
Sorcery send notification e-mails and so be aware that the new version
is now installed (in case they missed it when doing a queue (perhaps
automated)).

<snip>
> The idea I proposed above would also help prevent the horrendous
> breakage. Of course, that admin gets around to updating the software
> when they get around to it. Which may mean that they don't update the
> spell in a long time. So another shorter term solution to the annoyance
> is a sorcery hold. I don't think that gimping the package management to
> leave files around is a good solution. I think that better management of
> the upgrade path is a better solution.

The admin can remove the files when they are sure the upgrade has
worked. Having "everyone" hold a spell because it's a problem is a
problem itself, IMO, and I see this as a "needs fixing."

Perhaps a way of cleaning out old files (this would apply to web apps as
well as kernel modules) would be handy. Another addition to `cleanse` to
do so might be handy, but a few issues I see with this approach as well:
1. How does cleanse know when files are no longer needed?
2. Will these files be permanently wiped or compressed and stored
somewhere?

1. For kernel modules, just check if the kernel image exists that they
were built against, and if not, they are no longer used. For web apps,
check the "$SPELL -> $SPELL-$VERSION" symlink to determine if the old
version may be removed (the symlink does not point to the old version)
or not.

2. Even with ARCHIVE="on" cleanse will remove the old archive, removing
any copy of the old files which may be around.

Mainly for #2, but also #1, I would prefer to let the admin clean up the
files. A `gaze aliens` will let him/her find files which are no longer
tracked and he/she may decide if they should be removed or not.

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page