Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] menuconfig for casts

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: "Andrew \"ruskie\" Levstik" <ruskie AT mages.ath.cx>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Fri, 16 Dec 2005 20:05:57 +0100

> > I'd think that spell scripts (apart from install) should only (be able
> > to) access system information in a read-only way and store their
> > config/do their compilation in a confined place. And besides what is
> > allowed for them to do, what is possible in reality? Can one guarantee
> > a certain set of commands to be available to the scripts (sed, perl,
> > ...) even on a very, very minimal system? How far does the turing
> > completeness go in reality?
>
> Hmm. If you allow to run perl, you can do perl -e 'system "rm -rf /"'.
> Those are scripts that are running with root privilegues. I don't think
> that the situation is different for rpm or deb, you just have to trust
> your package provider :)
>

I thought this was being worked on long term goal to have build being done as
a lower
privlege user and only install as root.

> > unless the script created - or worse: modified - some random files in
> > the system... I think spells should be at most allowed to write to a
> > temporary directory (subdir of cast/xxxx ?) and the unpacked source
> > directory, of course.
>
> Well, spell should behave as you described, if it does not, it's
> probably bug (unless there's reason ofcourse). But why limit ourselves ?
>

> > OK, you have quite some points there... I still think that in
> > principle the configuration could be done in a menuconfig-like way (on
> > the look-and-feel side, not internally) for a whole cast together, but
> > I see that the spell design would have to take care of being able to
> > go back and forth, support enabling and disabling of things. So even
> > if this could be done, it won't be done in the near future.
>
> I would say that this is feature creeping, sorry ...

I really don't think a menuconfig style menu is a good thing...

> > What I think is possible, then, is to drop the whole-cast approach and
> > to provide sorcery functions for the spells that do what some spells
> > (glibc with locales) do now with self-coded dialog scripting, I guess.
> > Extending the API so that spells can easily let their configuratuion
> > step appear as (nested) menus.
> >
> > Instead of
> >
> > config_query VAR "Question?" y
> >
> > for every option, I'd like to specify the list of options/questions
> > somehow
> (with some means to indicate relationships between options) and execute
> >
> > config_menu
> >
> > to get my variables set by the user working in a menu. I have to think a
> bit about the DEPENDS file since I'd like to have it integrated, too.
> >
> > This approach leaves existing spells unharmed (would they get an error
> if they define a config_menu function themselves?) and would give me the
> non-linearity that I want for the more complex spells.
> >
> > Is there opposition against that API extension (supposed that probably
> I'll do the work and manage to write such a menu function / its helpers to
> specify the structure)?
>
> Well generally no ( you can create whatever you want in your local
> grimoire, after all ). The only think I can think off is that the cast
> is supposed to work even unattended, there are timeouts for each
> question. I'm not sure how would you do that with menuconfig style ui.
>

Imho nothing wrong with writting the extension as long as it doesn't break
anything current. You did try using the sorcery interface to cast spells
though did you not?

--
Andrew "ruskie" Levstik
Source Mage GNU/Linux Games grimoire guru

Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html

Key id = 9A5117F8
Key fingerprint = 6731 FEF2 99A8 4672 5962 69AB 3DAF DA67 9A51 17F8





Archive powered by MHonArc 2.6.24.

Top of Page