Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Improved API for query and store config information

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Improved API for query and store config information
  • Date: Fri, 19 Mar 2004 19:45:54 -0800

I'll try and brainstorm. You have some good example situations.

>
> It can be rather annoying in some cases. Here's an example that happened
> to me recently. I did an unattended system-update. I had samba installed,
> but a new query had been added to CONFIGURE for active directory support,
> defaulting to yes.
I see now, so one improvement may be to add a 'during_upgrade' or
'unattended' variable, and a default_answer_during_upgrade (spare my
verbosity). Then query could override spell writers default answer
with the user specified one, which would crunch all the answers one way
or another.

> This in turn added openldap and krb5 to the install
> queue, triggering all sorts of other spells to rebuild with kerb and ldap
> support. I came back and the update was finished. When I dispelled krb5
> and openldap, the spells that had been triggered to rebuild with kerberos
> and ldap support were *not* triggered to remove that support.

I've never been happy with the triggering mechanism, IMO they should
be dealt with as follows: during the initial CONFIGURE/DEPENDS question
period triggers should also ask the user what they would like to do, then
according to that do something later on. I also thought that triggers
(at least the ones that go off after a certain spell casts) should go
into the makefile:

foo : bar baz
cast -c foo
cast -c spell_that_foo_triggered

rather than what we do now, which is bundle it all up into a call at
the end of cast_spell.

Another nice extension to triggers would be to have sorcery menu options
for them:
default (do whatever the default action is, always)
yes (always do them)
no (never do them, screw them, i hate them)
queue (stick them in some queue for me to run later)

These could also have a prompt bit set on them, which when set means that
the user will be prompted about them with the default answer according
to their choice of the aforementioned 4 options.


>
> So there is definitely some room for improvement here. An installed spell
> should not install any new dependencies on an update unless they are
> required. Many of the cases where on_cast/cast_self triggers are used
> should also have on_dispel/cast_self.
Agreed. Any other suggestions beyond what i've come up with?
>
> Just some observations. Not show stoppers, but will probably save users
> (and anyone helping them in irc) from some headaches.
I think I'll put this on my list of projects to do after the BUILD split
stuff gets taken care of. Or maybe before depending on how motivated I
am ;)

>
> Too much sun today ... I apologize if this makes absolutely no sense. ;-)
makes perfect sense to me.

-Andrew

--
________________________________________________________________________
|Andrew D. Stitt | astitt AT sourcemage.org |
|irc: afrayedknot | afrayedknot AT t.armory.com |
|aim: thefrayedknot or iteratorplusplus | |
|Grimoire Guru ham/smgl, Porting Team Lead | ftp://t.armory.com |
|Author and Maintainer of Prometheus | |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page