Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Thomas Orgis (c0695802d6900775e09054cef09412bdd1fd8647)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Thomas Orgis (c0695802d6900775e09054cef09412bdd1fd8647)
  • Date: Tue, 23 Jan 2007 00:52:37 +0100

Am Tue, 23 Jan 2007 04:09:00 +0500
schrieb Pol Vinogradov <vin.public AT gmail.com>:

>> TRACK_ROOT is used to locate files on system, INSTALL_ROOT is a place
> where files will be installed.

My view:
INSTALL_ROOT = location where stuff gets installed (mental
picture: usually a chroot dir to be prepared)
TRACK_ROOT = "This describes what prefix should be given to
files installed in the install log"... I see this relating to the view
from inside the chroot (if it is one); with TRACK_ROOT=/smth the file
installed under /smth/file appears as /file in install log...

I must say that I don't really dig that wiki page... but I thought that
I got the meaning of INSTALL_ROOT and the point that the usual spell
files (normally INSTALL) deal with this one only.
smgl-fhs creates the whole tree under $INSTALL_ROOT. init.d puts
various files under $INSTALL_ROOT, reates /dev entries under
$INSTALL_ROOT.
There is one mention of TRACK_ROOT in init.d INSTALL and that is about
a symlink being prepared for runtime (inside $INSTALL_ROOT, perhaps).

> so, imagine: i changed INSTALL_ROOT
> to /smthg, there's no passwd and shadow (nor groups nor gshadow) and
> grpck checks unexistant files... imho, it's wrong

When you install a chroot system, you intend to have account files
_inside_ it. When there are none yet, you don't say yes to the question
(default is no now). You are the expert when using the *_ROOT vars.
I don't claim that our current account system really handles this now
this way.
groupadd works on /etc, useradd works on /etc. IMHO they should be made
to work on $INSTALL_ROOT/etc.
It happens to be possible for pwck and grpck to specify the files, so I
do it.
This does not change the fact that our account management is broken
with the whole $INSTALL_ROOT idea, when we use INSTALL_ROOT as chroot,
but it is a step to at least dig the idea in that it should be
different (yes, I am still on the task to change the account stuff...).
When we do _not_ intend to create a chroot ... would we really install
the shadow suite of basic account tools to /some/place to manage stuff
in main / ?

I reckon that when using (and extending) castfs, stuff is tricked to
use $INSTALL_ROOT/etc files anyway even if it tries to access /etc
files.

Well, rationale: Can someone with more basic understanding (andrew?)
clear up the situation?
http://sourcemage.org/node/1285 mentions sorcery state files in
connection with $TRACK_ROOT... not general spell/config files....

At some point, some significant subset of devs should know how to handle
these vars with some confidence, let alone ordinary "power users".


Thomas.




Archive powered by MHonArc 2.6.24.

Top of Page