Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

Eric Sandall wrote:
> Fellow web app users,
>=20
> In looking to update Drupal to 5.1 (I'm trying out Drupal for my weddin=
g
> to SweetPotato website ;)) and talking to a friend who uses Drupal
> (binford2k), it seems that our current setup is dangerous.
>=20
> Let me briefly explain. Our current setup, by default, installs to
> /usr/share/www/drupal/. When installing the same version as already
> installed, this causes no problem, but when we do an update, Drupal has=

> a few steps[0] which must be taken before the site goes live. When our
> spell updates, it will be replacing the currently installed Drupal
> version with one that is, most likely, incompatible with installed
> themes and modules and, possibly, which will break (or break with) the
> current database.
>=20
> My proposal:
> Install Drupal to versioned directories (e.g.
> /usr/share/www/drupal/5.1.0/) and leave the old directories alone (a la=

> kernel modules via the excluded filter). This will allow for updates to=

> Drupal to be installed, but the prior version still running from
> httpd.conf's DocumentRoot still set to the old version (e.g.
> /usr/share/www/drupal/4.7.6/). The admin may then at his/her leisure,
> copy the sites/* files to the new directory, dump the database for
> safekeeping, disable all non-core themes/modules, set DocumentRoot to
> the new location, run the upgrade script, and copy modules/themes over
> to test and update them for the new version.
>=20
> This will allow for future upgrades of Drupal to be installed *without*=

> wiping the current install of Drupal. The admin may upgrade at any time=

> afterwards.
>=20
> I believe this should be done for *all* spells which install to
> /usr/share/www (which should be all web-based apps, IMO), but that's fo=
r
> another day. We can say Drupal is the proof of concept for this. ;)
>=20
> My quandary:
> How do I setup this new method (assuming no one finds significant
> problems with it ;)) without breaking the old? Possible solutions are:
>   1. Use another directory for the new Drupal setup (e.g.
> /usr/share/www/drupal_roots/)
>   2. Continue to use the current directory (/usr/share/www/drupal/) and=

> somehow migrate the old files to the new layout (probably just use 'old=
'
> as the mentioned version folder). This would break the current
> httpd.conf, which I don't like.
>   3. Continue to use the current directory (/usr/share/www/drupal/) and=

> just put the versioned directory under it (e.g. drupal/5.1.0) and let
> the admin clean out the old Drupal files when done. This does not break=

> the current Drupal install (I asked) and also doesn't have two Drupal
> directories. The worst this one does is, possibly, confusing the admin
> if they are not aware, but it should be obvious.
>=20
> I prefer option #3, with #1 a fallback if there are too many problems.
> Option #2 is there for completeness and I most likely will not use it.
>=20
> Thoughts? Complaints?

I don't like leaving around the extra versions of stuff. They'll never=20
get disposed of. They fall out of the tracking system. Also, I'm not=20
certain this is necessary for ALL apps. It's not needed for moinmoin.=20
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=20
coming up with something that doesn't suck.

Technically it is the admin's responsibility to ensure that the upgrade=20
they're about to perform isn't going to break it. If it's absolutely=20
necessary that both versions exist at the same time to do the upgrade,=20
then we have a problem. If the problem is just that an unattended=20
upgrade will break things, it's not a problem at all. It is not our=20
responsibility to make upgrades happen when they involve changing=20
application specific stuff (database tables, configuration files,=20
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=20
about it. If not, then the admin needs to pay more attention before they =

upgrade their primary webserver software....

David

Attachment: signature.asc
Description: OpenPGP digital signature