Re: [avrdude-dev] Yet another config parameter

[Theodore A. Roth]

On Fri, 21 Feb 2003, Brian Dean wrote:

:) 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.

Let me see if I can get the install to do make a backup. It would
actually not be too hard to add a custom install rule to do it I
think.

:)
:) 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?

I don't think there is a consensus.

I think this is a pitfall of having a configure file. You will always
have to deal with the potential of screwing up someone config file,
either buy blowing it away, or by changing the format. There's no easy
way around this.

Also, ideally, you would want people to contribute config
info not in the dist back. Having a local config file, makes that less
likely (for some people).

I think that (on unix systems) ${prefix}/etc/avrdude.conf and
~/.avrdude.rc are sufficient and the standard way to handle config
files. /usr/share (or /usr/local/share) are, I believe, reserved for
data files that are platform neutral (e.g. icons).

Ted