Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Tue, Aug 09, 2005 at 11:12:01AM -0700, Eric Sandall wrote:
> On Tue, 9 Aug 2005, Sergey A. Lipnevich wrote:
> > I agree with this. However, the suggestion was to improve the casting
> > process, not to store complete account info in spells. Mapping between
> > accounts and number-ids can be kept centrally, but the instruction to
> > create a specific account/group may be part of the spell in a systematic
> > way. In comparison with init scripts, central ID map and installation
> > routine would be similar to smgl_init code included in every script, but
> > having some kind of pointer to create an account in a spell would be
> > equal to presence of init.d/<script> and init.d/<script>.conf files.
> 
> One of the points of moving it out of Sorcery was so the Grimoire Team
> could update the IDs without a new Sorcery release as well as modify
> the account setup, again, without modifying Sorcery.
> 
> Creating a specific account/group is already there in a systematic
> method: use `create_account` where you want the accounts created. If
> you're wanting the account creation to always happen in the same place
> then we just need to write down that `create_account` should be called
> in file <blargh> if it's going to be called at all.

I think the disagreement isn't over what to call the use of a function 
versus a variable in DETAILS.  I think it's between whether or not 
account creation is common enough to pollute the DETAILS namespace which 
would require sorcery modification.  Init scripts are about as common as 
user creation, I think -- the point I think the sorcery team would make 
is that the less that has to be parsed in sorcery itself the better.  
Variables have to be explicitly checked -- functions don't.  In a 
general movement toward modularity, the init script handling might be 
moved out into grimoire functions too -- I think that's one design goal 
the sorcery team is trying to do.  For these two reasons, I suspect 
without a design realignment, we would want to keep as much as possible 
out of DETAILS.  On the other hand, the point of DETAILS is to include 
as much "basic handling" as to make the vast majority of programs 
installable without any helpers.  This is why downloading is handled in 
DETAILS and spell metainformation goes in it, so I'm not sure what the 
sorcery team would want.

Personally, I think account creation could be considered "a dependency", 
and we might want to have depends_account "user" [ "group" ] and 
depends_group "group".  This might allow user account creation and 
deletion to be handled by the dependency resolution system where we can 
integrate it into dispel's fancy understanding of dependencies -- or we 
can create user spells that create the account on install and delete it 
on dispel, say smgl-user-named, smgl-usergroup-nobody-nogroup provides 
SMGL-USER-NOBODY + SMGL-GROUP-NOGROUP, which might involve no changes in 
sorcery itself.

Another thing we can do is add support to sorcery for arbitrary code 
dependencies -- to support "users" "usergroups" "groups" 
"kernelmodules", etc, and call them instead of spells, "potions", that 
we can add abstractly to the grimoire so as not to have to support them 
separately within sorcery.

Just some ideas ... :)

Seth

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454  E082 99F0 69DC FDCE E733

Attachment: pgpJeRuqM6KkL.pgp
Description: PGP signature