[arch-general] dovecot.conf kills update (conflicting file)
Guys, The dovecot update needs to be fixed. Currently, on upgrade you get: checking package integrity... (288/288) checking for file conflicts [#####################################] 100% error: failed to commit transaction (conflicting files) dovecot: /etc/dovecot/dovecot.conf exists in filesystem Errors occurred, no packages were upgraded. which is a bit frustrating. I know we talked a little about fixing dovecot (and other packages that break if upgraded but not restarted) so I don't know if this is related (I thought the discussion/debate was whether to add a one-liner advising that a dovecot restart was required), but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf Do I open a ticket or is this post enough? I have asked this question of whether to open a ticket on every bug or whether little items like this are preferred to be worked from the list w/o a ticket opened at least 3 times now and I have never received an answer (I apologize if I have missed it). I want to help Arch the best way I can. If you want bugs opened on everything, let me know -- I'm happy to open them. If you can work an issue from the list, then at least let me know "I'll take it from here" so I know things are not being missed. Thanks. -- 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
On 09/01/2010 07:44 AM, David C. Rankin wrote:
Guys,
The dovecot update needs to be fixed. Currently, on upgrade you get:
checking package integrity... (288/288) checking for file conflicts [#####################################] 100% error: failed to commit transaction (conflicting files) dovecot: /etc/dovecot/dovecot.conf exists in filesystem Errors occurred, no packages were upgraded.
which is a bit frustrating. I know we talked a little about fixing dovecot (and other packages that break if upgraded but not restarted) so I don't know if this is related (I thought the discussion/debate was whether to add a one-liner advising that a dovecot restart was required), but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf
Do I open a ticket or is this post enough?
I have asked this question of whether to open a ticket on every bug or whether little items like this are preferred to be worked from the list w/o a ticket opened at least 3 times now and I have never received an answer (I apologize if I have missed it). I want to help Arch the best way I can. If you want bugs opened on everything, let me know -- I'm happy to open them. If you can work an issue from the list, then at least let me know "I'll take it from here" so I know things are not being missed. Thanks.
I forced the update and: warning: /etc/dovecot/dovecot.conf installed as /etc/dovecot/dovecot.conf.pacnew
IMPORTANT DOVECOT 2.0 UPGRADE NOTICE ------------------------------------ see http://wiki2.dovecot.org/Upgrading/2.0 make sure, you convert the dovecot.conf file New optional dependencies for dovecot libmysqlclient: for MySQL back end postgresql-libs: for Postgres SQl back end ( 8/289) upgrading empathy [#####################################] 100% To use Empathy you need to install at least one Telepathy connection manager.
Great job on the notice :p -- 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
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.
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? -- 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
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).
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
On Wed, 2010-09-01 at 23:35 -0500, David C. Rankin wrote:
On 09/01/2010 06:08 PM, Ng Oon-Ee wrote: <snip>
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??
Yes, that's what I'm saying.
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?
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?
You seem to be quite uninformed about what packaging actually is. Various statements you make about 'dovecot installer' and 'update killing complaint' indicate this. Packaging is separate from the application, and the job done by the package management system is actually very simple at its core (keep track of files belonging to a package). Basically, 'installation' means something very different on a Linux system than on a Windows system (which is where your comments seem rooted). If you would take some time to try and understand the various things pacman does, you'd save yourself and others a lot more time on the various issues you bring to this list. Cheers, Ng Oon-Ee
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.
On Thu, 2010-09-02 at 05:39 -0400, Baho Utot wrote:
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.
Actually, the proper thing to do is stated in the post-install message. The behaviour you're talking about is not done by pacman, because with dovecot 1.2 dovecot.conf was not part of the dovecot package, as already mentioned.
On 09/01/2010 06:08 PM, Ng Oon-Ee wrote:
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.
OK, Now let's turn this conversation around and see if we can't make Arch better. I agree with all you said, and yes, I understand the 'packaging' and installer separation and what pacman does/doesn't do. What I want to explore is what additional effort would it take to identify and make the packaging process (for core server apps especially - mail/apache/etc.) more robust so that pacman can be made 'aware' of mandatory config files that should be expected? Additionally, there needs to be a 'non-critical' check that is employed for the times when an already installed font causes the install to fail. This isn't a giant problem, but it is an annoyance. Over the past 1.5 years on 8-10 Arch boxes, I have run into a dozen issues like this. Some for something as simple as a specific font already being installed which causes the install to stop as mentioned above. I'm not knocking Arch, I'm just trying to explore how much work it would take to make pacman just a little smarter so it avoids some of these things. That is what I DON'T know. The way I look at it is if Arch is going to keep moving forward, kicking ass and gaining market share the way it has in the past, then these are some of the things I notice that, if fixed, will add some of the required 'polish' to Arch to allow it to continue do so. Nothing more, nothing less. If it is too much work from a cost/benefit standpoint, then just throw this in the "Arch Ideas" files for later or hit 'del'. -- 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
On Thu, 2010-09-02 at 23:02 -0500, David C. Rankin wrote:
On 09/01/2010 06:08 PM, Ng Oon-Ee wrote:
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.
OK,
Now let's turn this conversation around and see if we can't make Arch better. I agree with all you said, and yes, I understand the 'packaging' and installer separation and what pacman does/doesn't do. What I want to explore is what additional effort would it take to identify and make the packaging process (for core server apps especially - mail/apache/etc.) more robust so that pacman can be made 'aware' of mandatory config files that should be expected?
That's the thing, pacman IS aware of it (post dovecot 2). What you're requesting, if I read correctly, is some sort of 'intelligent input' that 'package A tends to need config file B, and font C, D, E, even though they're not in the package at this point they may be in the future'. <snip>
The way I look at it is if Arch is going to keep moving forward, kicking ass and gaining market share the way it has in the past, then these are some of the things I notice that, if fixed, will add some of the required 'polish' to Arch to allow it to continue do so. Nothing more, nothing less.
I very much doubt 'moving forward, kicking ass, and gaining market share' is on the to-do list of any of the devs. There's a whole different mindset here, chasing a larger user count is not the purpose. That being said, it would probably be possible to implement something like what you seem to be suggesting. I doubt it ever will though, because this IS very much a corner case.
On 09/03/2010 01:11 AM, Ng Oon-Ee wrote:
That being said, it would probably be possible to implement something like what you seem to be suggesting. I doubt it ever will though, because this IS very much a corner case.
Cool -- now that's a clean answer. On to the next improvement idea... -- 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
On Thu, 02 Sep 2010 23:02:53 -0500, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
I'm not knocking Arch, I'm just trying to explore how much work it would take to make pacman just a little smarter so it avoids some of these things. That is what I DON'T know.
The work it would take is not the only problem. I (and probably other people too) don't want Pacman to be too smart. Because it does only what it must in a conservative manner, I can understand what it does and fix my system if needed. For instance, I had the same problem with Dovecot and I understood immediately what had happened so I changed my configuration file and it didn't crash on reboot. The more things a tool does, the more difficult it is to understand. Aptitude is probably "smarter" than Pacman but I screw my system up a lot more when I use it on Debian than when I use an Arch box. That's the advantage of simplicity: as an operations guy I prefer to run several commands and edit a bunch of configuration files but know perfectly what I've done than run one command that works 99% of the time but doesn't give you a chance to fix the system when it screws up. -- Pierre 'catwell' Chapuis
participants (4)
-
Baho Utot
-
David C. Rankin
-
Ng Oon-Ee
-
Pierre Chapuis