Public SourceMage Discussion List

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

Well, yeah, in a business environment, you're best never to allow 
deleting of anything non-transient, period. (Also, data's most of the 
time worth more money than the harddrive space).

I just think the "option" to be able to keep your system clean would be 
nice for somebody who desired it (along with deleting an account would 
be the option to delete their home directory and/or any data associated 
their user.)

I'm not opposed to the ACCOUNT variable with a sane syntax "user:group" 
perhaps similar to chown's syntax.  I await the sorcery team's input on 
whether or not they think this is warranted in their judgement (and the 
ensuing discussion).  Ultimately they get yes/no rights on what goes in 
or not.

Seth

On Tue, Aug 09, 2005 at 03:16:17PM -0400, Sergey A. Lipnevich wrote:
> Thanks for putting it so clearly Seth! Yes, I completely agree with this
> and the ideas. Except one thing actually: once an account is in use, it
> must never be deleted, that's an accountability violation, so I think we
> don't need to concern ourselves with account deletion. Maybe something
> as simple as ACCOUNT variable in DETAILS would suffice.
> 
> Sergey.
> 
> On Tue, 2005-08-09 at 12:06 -0700, Seth Alan Woolley wrote:
> > 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.
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> 

-- 
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: pgpRXFnJxLaAk.pgp
Description: PGP signature