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
