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:
>>>> but in any event, related or not,
>>>> dovecot should update without failing due to the existing dovecot.conf
>>> 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.
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