Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

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).

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?

-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