[arch-general] dovecot.conf kills update (conflicting file)

[Ng Oon-Ee]

On Wed, 2010-09-01 at 11:58 -0500, David C. Rankin wrote:
> On 09/01/2010 08:59 AM, Ng Oon-Ee wrote:
> > On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
> > <snip>
> >>   but in any event, related or not,
> >> dovecot should update without failing due to the existing dovecot.conf
> > <snip>
> >
> > The dovecot.conf file was created by you previously, hence why the
> > update is failing. The new dovecot package provides dovecot.conf (I
> > think because upstream provides it).
> >
> > Pacman gives an error in situations like this, as it well should, since
> > I doubt anybody wants their configs wiped out. As such I don't think
> > this is even a bug.
> >
> >
> 
> ? Que?
> 
> 	I thought that was what was supposed to be handled by .pacnew and .pacsav. Of 
> course there will be a dovecot.conf. (dovecot won't work without it) Everybody 
> knows that. Why should/would an Arch update not be able to handle that simple fact.
> 
> 	You know more than I, but to me, it looks like a bug that Arch needs to be 
> smart enough to fix. I propose that whoever maintains dovecot for Arch fix the 
> install to install the new dovecot.conf and dovecot.conf.pacnew. That way we 
> don't blow up a 288 package update just because the dovecot installer isn't 
> smart enough to know that if dovecot is already installed -> expect a dovecot.conf.
> 
> 	Do you disagree with that? If so, why?
> 
Files on the filesystem either belong to a package or they don't.
dovecot.conf didn't, because the older dovecot packages (1.2-x) did not
have the /etc/dovecot.conf file. You created that file yourself when you
set dovecot up the first time.

Now, the dovecot 2.0+ packages DO have that file. What else do you want
pacman to do when the following is true:-
1. Package A did not use to own file B.
2. Package A now owns file B.
3. File B already exists on the filesystem.

The file may not be a conf file. It may be a binary, a library etc. It
may not even be intended for package A, but may belong, say, to package
C. In any case, since YOU created it, you're responsible for deciding
what you want to do with it.

Pacman helps you manage your system, it doesn't (and shouldn't) try to
make assumptions about stuff like this, because that's your job. You
know your system better than anyone else (ideally).

And your assertion about 'blowing up a 288 package update' is nonsense,
by the time you reach this error the downloads are done (so they don't
have to be repeated) and no files have actually yet been installed.
Re-run pacman -Su after fixing the problem and everything just installs
as it should have.

Finally, there is no 'dovecot installer'. It is a package, a compressed
collection of files. dovecot.install is mainly for post-install messages
or perhaps some system configuration using common tools. Not to create
configuration files from scratch (that's your job).