

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
4 messages in net.sourceforge.lists.courier-sqwebmail[sqwebmail] some notes about upgrade ...| From | Sent On | Attachments |
|---|---|---|
| Kurt Bigler | Apr 11, 2005 6:43 pm | |
| Brian Candler | Apr 12, 2005 12:34 am | |
| Paul L. Allen | Apr 12, 2005 5:02 am | |
| Kurt Bigler | Apr 12, 2005 5:58 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | [sqwebmail] some notes about upgrade from sqwebmail 3.5.0 | Actions... |
|---|---|---|
| From: | Kurt Bigler (kk...@breathsense.com) | |
| Date: | Apr 11, 2005 6:43:15 pm | |
| List: | net.sourceforge.lists.courier-sqwebmail | |
These issues are resolved now, however I thought it would be worth reporting these experiences. Some of this is feedback on the doc, some on the install process.
It has been over 2 years since I upgraded sqwebmail (I was at 3.5.0) and as a result I lost my familiarity with some of the nuances of the install process, and so I remade some old mistakes.
(1) Somehow I referred to the wrong old config.log file when creating my current configuration. As a result I had configured with the wrong spell-checker pathname:
--with-ispell=/usr/bin/ispell
instead of
--with-ispell=/usr/local/bin/aspell
As it turns out, there *is* no /usr/bin/ispell on my system. However, I did not discover this readily, because the maillog file was showing the error:
sqwebmaild: ispell_run: incomplete result from ispell
If there were any problem with the executable not being there, I'd off-hand have expected this error instead:
ispell_run: fork_ispell failed
The fact that I got the other error when the executable path I configured did not exist seems very strange and I can't understand it.
So I ended up on a wild goose-chase for a little while, concerned about dictionary names, and so forth. Then I found an archived email exchange I had on the old sqwebmail list, and from this I figured out what had happenned.
(2) In the process of doing this upgrade I lost the customizations I had made to my TIMEZONELIST file. This turned out to be ok, though because the new TIMEZONELIST is so ample with its hundreds of entries for around the world as to make my previous TIMEZONELIST of little value. It was so ample in fact that I went to some work to put some of the 30 or so more important time zones at the top so that they would not be so difficult to find.
However, I was still a bit surprised to lose the TIMEZONELIST file which somehow I didn't end up having a copy of in my source tree. It was apparently blown away by doing the make uninstall in the old source directory, something which surprised me because to me this is a configuration file, something that should have been part of the make install-configure process and not the make-install process.
When I corrected my ispell configuration problem (above) I had to do another make install for this and had another shock when my work on the new TIMEZONELIST file done just hours earlier was lost, because the make-install blew it away.
But of course, I should have been modifying the TIMEZONELIST file in the soruce tree, I thought. But upon finding the file there, I discovered it was not the long TIMEZONELIST file that had been installed, but a short one with only 6 entries or so.
Apparently the install process added the additional entries to the TIMEZONELIST on-the-fly as part of the install process. Perhaps the additional entries came from some information on my system that wasn't there when I did the 3.5.0 install, and the differences I am seeing is not even a reflection of a change in SqWebMail itself, but rather a change elsewhere on my system. In any case the INSTALL file does not say anything about this.
So it looks like there is no good way to deal with this except to make a separate copy of the customized TIMEZONELIST file and to try to remember to replace it every time I do a make install.
I think those are the most important points. In general I'd like it to be a lot easier to understand the install/upgrade process, particularly the subtleties of the distinction between what is a configuration file and what is not, and in general how to pull an upgrade off without inadvertently losing something, or being forced to restore it from backup. In the case when something is installed by make install, I'd like to be able to update it in the source tree and do another make install to get it posted. Tentatively for configuration changes I'd also like to be able to edit them in the source tree too, and post changes via make install-configure. It also like if the "configuration file" distinction could be entirely intuitive, with everything that is a configuration file conceptually located in a single place if possible, and in any case not touched by an ordinary make install.
Thanks, Kurt Bigler







