Re: [avrdude-dev] Yet another config parameter

[Brian Dean]

On Fri, Feb 21, 2003 at 02:21:04PM -0500, Brian Dean wrote:

> Feel free to drop it.  On FreeBSD at least, I move the old one out of
> the way using a timestamp as part of the name, then install the new
> one.

(follow-up to self)

Er ... I used to do that.  Looks like that doesn't happen any more,
maybe that got lost with the autoconf merge.

Maybe we should keep the .sample around.  I know we had this
discussion before, and the right thing to do seems to be platform
specific, i.e., Windows does things a bit differently.

To keep from messing up someone's customizations to avrdude.conf, I
think we should do something like this:

        1. install avrdude.conf.sample in /usr/local/share/avrdude
           as avrdude.conf.defaults or something

        2. if there is no /usr/local/etc/avrdude.conf present, install
           one with the defaults commented out, i.e., this one might
           contain just:

                # default_parallel = "/dev/ppi0";
                # default_serial   = "/dev/cuaa0";

Then, when avrdude starts up in can read in the config files in order
of:

        /usr/local/share/avrdude/avrdude.conf.defaults
        /usr/local/etc/avrdude.conf
        ${HOME}/.avrduderc

With each later config file's entries taking precedence over earlier
entries.

That way, one can upgrade avrdude and we can always feel free to blow
away /usr/local/share/avrdude/avrdude.conf.defaults with the most
recent version, but administrator defaults and overrides set in
/usr/local/etc/avrdude.conf would be left untouched.  Same with
${HOME}/.avrduderc.

The only problem I can see with this is if someone defines their own
part and puts it in .avrduderc or /usr/local/etc/avrdude.conf, and
then we make a config file change where we need more information from
a part (happened just recently), then the old part entry in
/usr/local/etc/avrdude.conf will take precedence over the most current
stuff in /usr/local/share/avrdude/avrdude.conf.defaults.  This may
result in false bug reports, general confusion, etc.  But I don't see
any way around that, yet still preserving locally made customizations.

I don't know if we came to conclusion on this discussion previously
and I missed it?  Anyway, what do you guys think about the above?

-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/