Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

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