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

[David C. Rankin]

On 09/01/2010 06: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).
>
>

OK, I'm buying it. What you are telling me is that for 1X there was NO 
dovecot.conf (IIRC it was something like dovecot.conf.example because I compared 
something to my suse dovecot.conf when I moved to Arch)....AND... you are saying 
since 1X didn't have one, the fact that 2.0 does somehow causes the 1.x->2.0 
update to evade (or fall outside of) the way the .pacnew logic works because the 
2.0 install doesn't know about 1.x having a dovecot.conf??

That just seems wonky. So for httpd, it has a httpd.conf from the first version, 
so it doesn't complain when apache is updated or you get a .pacnew.

OK, then, this 1.2-2.0 transition should be the only dovecot update that craters 
the update do to the existence of the dovecot.conf file. So when I updae to 2.1, 
there should be no update killing complaint about the dovecot.conf.

Right?

Just seems weird that any package with a mandatory config would puke when it 
finds the mandatory config from a prior version actually there.

So far this dovecot update, *every* Archer that updates will have the update 
fail do to this problem, but the next update to 2.0-X should be fine, right?


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com