install-log-devel

[ID] chroot quandary

[Andy G. <unu...@op...>]

First, I removed the pre-chroot option, because the root option is all that's 
necessary.  (I should make root default to ${LFS} if set, otherwise to "/".)  
But that's not the issue.

The issue is configuration parsing.
(1) Defaults built into executable
(2) Configuration file
(3) Command line

This way stuff can be overridden on the command line.  But!  What if the user 
wants to use the --root=/mnt/chroot option?  /mnt/chroot/etc/install-log.rc 
should be scanned, right?  Wouldn't that override the command line options, 
possibly including --root?  This is screwed up.  And what if the new 
configuration file sets root to something else?  Should install-log check for 
a configuration file in the new location as well?  And what if the new 
location's configuration file points back to the old one?

Uhm, I'm confused.  The only solution I can think of is adding an internal 
priority counter to configuration settings.  Initially it's zero.  When set 
from the configuration file, it's set to one.  When set from the command 
line, it's two.  If an attempt is made to set an option with a higher 
priority (i.e. overriding a command line option from the configuration file 
[when scanned the second time]), nothing happens.

Furthermore, the ROOT entry cannot be set from the configuration file.  This 
removes the possibility of scanning more than two configuration files and the 
possibility of getting into an infinite loop (with two pointing at each 
other).

I'll try implementing this.  If you see anything that needs to be fixed in 
this scheme, share, and we'll go back to the old version and do it Right.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] chroot quandary

[James R. <jr...@fu...>]

On Fri, Jul 27, 2001 at 08:50:34PM -0500, Andy Goth wrote:
> The issue is configuration parsing.
> (1) Defaults built into executable
> (2) Configuration file
> (3) Command line
> 
> Uhm, I'm confused.  The only solution I can think of is adding an internal 
> priority counter to configuration settings.  Initially it's zero.  When set 
> from the configuration file, it's set to one.  When set from the command 
> line, it's two.  If an attempt is made to set an option with a higher 
> priority (i.e. overriding a command line option from the configuration file 
> [when scanned the second time]), nothing happens.

I can't really think of any other way to handle this, a priority counter might
very well be necessary.
 
> Furthermore, the ROOT entry cannot be set from the configuration file.  This 
> removes the possibility of scanning more than two configuration files and the 
> possibility of getting into an infinite loop (with two pointing at each 
> other).
> 
> I'll try implementing this.  If you see anything that needs to be fixed in 
> this scheme, share, and we'll go back to the old version and do it Right.

Ok, I can't think of many instances where you would really want to set ROOT in
the config, and a user could always alias it in the shell I suppose. If I think
of something though, I'll be sure to say :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/