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: David Kowis <dkowis AT shlrm.org>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Drupal (and other) install setup
  • Date: Fri, 01 Jun 2007 11:44:21 -0500

Eric Sandall wrote:
David Kowis wrote:
<snip>
I don't like leaving around the extra versions of stuff. They'll never=
get disposed of. They fall out of the tracking system. Also, I'm not
certain this is necessary for ALL apps. It's not needed for moinmoin.
It's not necessary for phpmyadmin, or phppgadmin.

It breaks our package management stuff if we leave it up to the admin to clean out the stuff. Hmm this will require much more thought before
coming up with something that doesn't suck.

Technically it is the admin's responsibility to ensure that the upgrade
they're about to perform isn't going to break it. If it's absolutely
necessary that both versions exist at the same time to do the upgrade,
then we have a problem. If the problem is just that an unattended
upgrade will break things, it's not a problem at all. It is not our
responsibility to make upgrades happen when they involve changing
application specific stuff (database tables, configuration files,
application data files). We've never done that.

So, what I'm saying is, if it's necessary to have both sets of files for that software on the drive at the same time, we should do something
about it. If not, then the admin needs to pay more attention before they upgrade their primary webserver software....

Correct, we do not do the upgrades for the admin. My goal here is to
make it so our updates do *not* break a currently installed setup (which
I think all spells should at least *try* to do ;)) whether or not the
admin scrutinizes his queue before casting (I've heard complaints that
some people don't bother with our spells for web apps as it's too much
work to watch the queue for them and take them out to deal with later).

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.


For web apps that do not have an upgrade path (e.g. phpmyadmin) then
this would not be used.

As for concurrent installs required, the steps are only to backup your
old Drupal config files, disable all modules/themes, move the old Drupal
directory, and then copy the new Drupal to the old location. Then you
copy over your configs, themes, and modules and test/update them for the
new Drupal.

IMO, the proposed method is the 'safe' approach to using a package
manager for (most) web apps. The current setup requires specific
monitoring of the admin to avoid horrendous breakage, which tends to
lead (from what I've heard) to the admin not even using the spell for
the web app. If our spells are so annoying/broken that people are
manually installing the packages, why do we even have a spell?

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.

David

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page