[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] Yet another config parameter
From: |
Brian Dean |
Subject: |
Re: [avrdude-dev] Yet another config parameter |
Date: |
Fri, 21 Feb 2003 14:36:18 -0500 |
User-agent: |
Mutt/1.4i |
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/
- Re: [avrdude-dev] Yet another config parameter, (continued)
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Joerg Wunsch, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Brian Dean, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Theodore A. Roth, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Brian Dean, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Theodore A. Roth, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Brian Dean, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Theodore A. Roth, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter,
Brian Dean <=
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Brian Dean, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Theodore A. Roth, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Brian Dean, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Theodore A. Roth, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Brian Dean, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, Joerg Wunsch, 2003/02/21
- Re: [avrdude-dev] Yet another config parameter, E. Weddington, 2003/02/21