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

[Baho Utot]

  On 09/01/2010 07:08 PM, Ng Oon-Ee wrote:
> 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).
>

The proper thing to do is to rename /etc/dovecot.conf to 
dovecot.conf.orginal, do the update and then merge/restore the 
dovecot.conf.orginal to/into dovecot.conf.

Then everyone is happy.