Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Jun 01, David Kowis [dkowis AT shlrm.org] wrote:
> Eric Sandall wrote:
> >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.

We don't need to modify sorcery for this.  Just add a PREPARE with a
warning they need to make sure they did the prep work for the upgrade and
requires them to say yes, or the update is dropped.  If we need that often,
make it a section- or grimoire-level function.

On Jun 06, Eric Sandall [eric AT sandall.us] wrote:
> Jaka Kranjc wrote:
> > The admin could also just set TRACK_ROOT=INSTALL_ROOT=/elsewhere and 
> > parallely 
> > install the new version.
> 
> I'd rather the admin *not* have to set custom configs for spells to have
> them *not* break on updates. ;) The point of my proposal is to have
> updates *not* break current installs and to not require constant
> attention from the admin. Yes, the admin can put the spell on hold, but
> if many admins are doing this it means, to me, that our spell (or
> method) is broken and needs fixing.

I think it means that upstream is being complex with their updates, and
that isn't really our problem.  If we don't let sorcery stop or start
services on install/uninstall/update I certainly don't think we should have
it try to be uber clever about other aspects of doing updates.  While I
don't have a problem with the substance of what you suggest, that substance
is basically parallel install so the admin can sort it out later.  We don't
really support parallel install, and the scenario of a bunch of untracked
files getting left for the admin to deal with is IMO horribly broken toward
the package manager and not a fix.

Our promise to users is that we'll install what they'd get if they followed
upstream's instructions.  If upstream's instructions for updates are more
complex than we can handle natively, we should leverage what interactivity
we do have to warn them of the extra work and leave it to them.

On Jun 06, Eric Sandall [eric AT sandall.us] wrote:
> 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)).

This is pie-in-the-sky, sorry.  If we're starting with a problem of admins
who can't be bothered to check their queues or know what their updates need
ahead of time, most of them are not going to go back and do manual
transitions or clean stuff up either.  I say just defer the update until
they've done the pre work.  Don't break it on them but leave it their
problem, not ours.

Attachment: pgprufZtxegfp.pgp
Description: PGP signature