> Ok, I just looked at line 307 to 344, where the 'case' is and then one > could get the idea that create and overwrite was the same action. :) > But these pointers bring new light over the "issue". However, I > think I > should have created the hints array and then just intersected it with > hintsAllowed and opts_available like: > > requested_actions=$(Hints_For $file) > allowed_requested_actions=$(Array_Intersect $opts_available > $hintsAllowed) > available_allowed_requested_actions=$(Array_Intersect > $allowed_requested_actions $opts_available) > > just for readability (but this code is nothing I've tested, so it > might > not work).
I have no idea why it's not like that already. I would've guessed it's because I didn't know what array intersect did at the time, but I used it immediately below the code those lines would replace. I'll go ahead and test this. If it works (I can't imagine why it wouldn't) I'll add it to CVS. > > The docs are really good, but I didn't know of that doc, so I tried to > figure out what was happening, just by looking at the code (but it > wasn't > going that well :) ) > > A thought: perhaps settings directed by hints should produce a > different > output (I know I'm drifting slightly ot here)? An example: > > ]UpdateSettings openssh > UpdateSettings: Current and default settings are different > > 1 mod: Settings/ssh/moduli > 2 mod: Settings/ssh/ssh_config > 3 mod: Settings/ssh/sshd_config > 4 del: Settings/ssh/ssh_host_dsa_key > 5 del: Settings/ssh/ssh_host_dsa_key.pub > 6 del: Settings/ssh/ssh_host_key > 7 del: Settings/ssh/ssh_host_key.pub > 8 del: Settings/ssh/ssh_host_rsa_key > 9 del: Settings/ssh/ssh_host_rsa_key.pub > 10 del: Settings/ssh/ssh_prng_cmds > > [...] > UpdateSettings: Not deleting Settings/ssh/ssh_host_dsa_key > UpdateSettings: Not deleting Settings/ssh/ssh_host_dsa_key.pub > UpdateSettings: Not deleting Settings/ssh/ssh_host_key > UpdateSettings: Not deleting Settings/ssh/ssh_host_key.pub > UpdateSettings: Not deleting Settings/ssh/ssh_host_rsa_key > UpdateSettings: Not deleting Settings/ssh/ssh_host_rsa_key.pub > UpdateSettings: Not deleting Settings/ssh/ssh_prng_cmds > > I cut away the "mod" parts as I didn't have any hints for them, but > for > the ssh_host* files I had the hint "skip", but perhaps the files > should > not be listed in the first list, or just a note that the behavoiur for > those files are already decided by hints? Same thing with the log > messages, the user might wonder why the files wheren't deleted (or > created/updated/anything). I just committed a small modification to UpdateSettings that says why it's doing what it's doing in each of its log messages. Unfortunately, getting the initial list to output something about hints would require a significant amount of code rearranging--the list-generating code would need to be aware of the hints file and the update mode--but it's a good idea. The next question would be: if the format of the initial differences list is going to change, /how/ should it change? I'm not sure I like the idea of removing 'hinted' files from the list entirely--one of the things that bothers me about a lot of package managers is that they don't really show you what they're doing (*cough* darwinports *cough*). But, I agree that the first list should indicate in some way which files the user is actually going to have to decide something about... Maybe the initial list should look something like this: ]UpdateSettings openssh UpdateSettings: Current and default settings are different UpdateSettings: 7 changes can be handled automatically 1 skip: Settings/ssh/ssh_host_dsa_key 2 skip: Settings/ssh/ssh_host_dsa_key.pub 3 skip: Settings/ssh/ssh_host_key 4 skip: Settings/ssh/ssh_host_key.pub 5 skip: Settings/ssh/ssh_host_rsa_key 6 skip: Settings/ssh/ssh_host_rsa_key.pub 7 skip: Settings/ssh/ssh_prng_cmds UpdateSettings: User interaction will be required for 3 changes 1 mod: Settings/ssh/moduli 2 mod: Settings/ssh/ssh_config 3 mod: Settings/ssh/sshd_config To be perfectly honest, this seems a little cluttered to me. I guess I'm a little out of practice :)... Anyway, it'd be nice to know what the new initial list should look like before I start trying to code it, since that may change just how much code has to move. - Dan has been gone too long, and needs to figure out how to install Gobo on his Mac > > /Jonas > > On Wed, 22 Nov 2006 20:42:57 +0100, Dan <[EMAIL PROTECTED]> wrote: > >> I just double-checked the UpdateSettings source and confirmed this. >> >> Take a look at lines 260 thru 279. UpdateSettings builds an >> opts_available array based on $difftype. 'create' is only added if >> the file doesn't already exist in /Programs/Foo/Settings. Further >> down (289), hints are only used if they're in the opts_available >> array. So, even though the create action and the overwrite action are >> technically the same, a 'create' hint will only have an effect on >> UpdateSettings' behavior when current is missing. >> >> The docs I linked to have the available hints broken into categories >> along with a description of when each one is available, or you could >> just read the source now that you know where to look :) >> >> >>> Assuming everything still works the way I documented it long long >>> ago, create doesn't overwrite. "overwrite" overwrites. >>> >>> UpdateSettings determines what it can do before it determines >>> what it >>> should do. If a file already exists, "create" won't be possible, >>> so a >>> create hint will be ignored. >>> >>> http://gobo.kundor.org/wiki/UpdateSettings#Update_Commands >>> >>> >>> >>>> I tried to find a hint, but it seems like there is no "use default >>>> when >>>> current is missing". The hints "create" and "overwrite" both do the >>>> same >>>> thing and "skip" does nothing. I'd like "create" not to overwrite >>>> if the >>>> file already exist, or have I missed something? >>>> >>>> -- >>>> /Jonas >>>> >>>> _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
