Re: [Solved] Unable to configure .fetchmailrc

Roger Price wrote: 
> On Mon, 17 Aug 2026, Michel Verdier wrote:
> 
> > What is your version ? Here I have fetchmail 6.4.39-1
> 
>   rprice@titan ~ apt show fetchmail
>   Package: fetchmail
>   Version: 6.4.39-1
> 
> > And man fetchmail or fetchmailrc shows :
> > GENERAL OPERATION
> >        Command-line  options  override ~/.fetchmailrc declarations.
> 
> When I started to write the message, I had not yet understood that 
> « Command-line options override ~/.fetchmailrc declarations » means that Debian 
> 13 replaces ~/.fetchmailrc with /etc/fetchmailrc .


That's not quite it, either.

The normal and expected course of configuration overrides:

1. If you call fetchmail with options, those take precedent for
this run.

2. if .fetchmailrc exists in the home of the user running it,
that is used. If not...

3. if /etc/fetchmailrc exists, that is used.

4. if none of these things happen, whatever behavior is listed
as defaults for the command happens.


This pattern repeats across many, many programs. Sometimes the
user's config file (step 2) might be expected to live in:


~/.programname
~/.programname/  (a directory)
~/.config/programname/
~/.local/share/programname/


Or something weirder.

Sometimes the system config file (step 3) will actually live
somewhere in /usr/share/programname/ in which case it might be
symlinked to /etc/programname or it might supply defaults that
can be overriden in /etc/programname/.

It would be nice if everybody agreed on a single convention, but
the great thing about standards is that there are so many to
choose from, and everybody seems to come up with a better idea,
which adds a new standard. There is an XKCD for this.

This is made more wonderful by the nature of Debian: a volunteer
project in which people cannot be ordered to do things, only
told that if they do particular things their projects won't be
accepted by Debian itself.

This is the best of all known compromises to produce freedom.

-dsr-