>> >> the current /etc/security (along with the current /etc/rc.subr and the
>> >> current /etc/defaults/security.conf) already has a mechanism for doign
>> >> rcs based file backups.
>> >
>> >It is useless from the point of view of using the result to help
>> >facilitate upgrades.  Branches must be used so that changes between
>> >released versions can be tracked.
>> 
>> it's not on a branch yet.  it will eventually be on the 1.6 branch
>> when that happens.  i don't think it will show up on the 1.5 branch.
>
>I'm not talking about OS release branches.  I'm talking about checking
>in release versions of the files listed in /etc/changelist onto a branch
>and local changes onto the trunk (or vice versa) so that changes between
>releases can be detected and thus so that an automated merge tool that
>works very reliably can be built.  Think of it as sort of like
>vendor-branch support in CVS, but without using CVS!  :-)

oh...that.  can you suggest as easy way to do that?

please note that the rcs backups mechanism doesn't change the tags
from the released files, so you could just compare the file you've
currently got with the released file of the same number.
 
>> any sysadmin is free to add files to rc.d and as such, they may wish
>> to track changes to those scripts.  alternately, any sysadmin can also
>> add files to changelist if they feel like it, and as such, must not be
>> forced to lose if files they add have the same basename as other files
>> listed in the changelist.
>
>That's more or less exactly what I said -- I just meant that /etc/rc.d/*
>files should NOT be in the distributed version of /etc/changelist, so
>therefore they are bad examples to use in this discussion!  ;-)

okay, so it's a bad example.  gimme a better one.  :P

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."