[Dovecot] Can I install in the following fashion?

[Lior Okman]

The problem you are describing is solved with tools like RPM and DEB.

You can install/remove an entire package with a single command, you
can verify the installation with a single command, you can safetly
upgrade with a single command, and safetly revert to an older version
with a single command.

These tools allow you to find out exactly which file belongs to what
package, and they prevent conflicting files from two different
packages from being installed. Not to mention (almost) automatic (at
least on debian) dependency resolving for packages.

If you're using Debian, you can just "apt-get install dovecot-imap
dovecot-pop", and have the dpkg handle all of the issues you
mentioned. If you're using an RPM based distro- try yum or apt-rpm.

Lior


On 3/6/06, Stewart Dean <sdean at bard.edu> wrote:
> <permit me my perhaps foolish preference...an explanation>
> I run mail service for a small college.  I've long joked that if someone
> stole the mail server, the phone would ring before the alarm (which has
> a 1 minute delay) did, that the user base expected 25x8x367 coverage.
> Making updates/upgrades to the mail server feels like a tightrope walk
> with no net.  I always appreciated UofWIMAP because there is one binary.
> Doing and upgrade or backing it out is simplicity itself.  I could
> compile the single binary on my compile machine, test the same binary on
> my testbed, and then drop it in my production machine and it would work
> with a minimum of surprises.  So portable, so predictable, no security
> risk of a compiler on a production machine.
> Of course, /most/ of open source software has all these bits and pieces
> scattered everywhere.  Oh, it may install initially just dandy, but come
> the day when It's Time For The Upgrade....
> 1) can I do it quick and clean and
> 2) can I recover to what I had before quickly and correctly if the
> upgrade flops??????
>
> Alas, Dovecot is sprinkled in many, many pieces...but at least, I think
> (right?) that they are all in the prefix-dir.  Gulp. So. I am hoping I
> can do this:
> Build/Test Install
> 1) build/install in
> /usr/local/dovecot_bld/ Build###
> in the expectation that everything will be stuck down there.  I don't
> want to put it into /usr/local/ because it will be in there with
> everything else....no way to get just the dovecot stuff..
> 2) tar up the contents of my prefix directory and extract it over on my
> testbed under /usr/local/dovecot. Notice that the path to dovecot's
> "stuff" has changed from
> /usr/local/dovecot_bld/ Build###
> to
> /usr/local/dovecot
> I'm hoping that this won't be a problem.  I will point the line in inetd
> at it and Everything Will Work.
> 3) Assuming I don't change anything and everything tests out
> (flawlessly!), I.............
>
> Introduction to Production
> (assuming that all the mailboxes, homedirs and the like have been sorted
> out)
> 1) make a tarball of the current working dovecot executables dir
> (/usr/local/dovecot)
> 2) extract the tarball there as before on the testbed machine and
> everything is fine.
> 2) if the update flops, I can bring back the tarball of the previous
> Dovecot incarnation
>
> My Questions:
> A) Will this work or are there dependencies I'm not aware of?
> B)  Is there Some Better Way or.....
>
> I have this ongoing <ahem> discussion with the Open Source wonks that
> delight in many, many modules, libraries, etc.  I /know/ the reasons a
> developer would want to do things that way, but, for those of use
> fielding the application, it's /so/ much easier and success/failure
> recovery is /so/ much more likely if....there are only one or two or
> three chunks that we can drop in or quickly back out.
> I realize that the developer is coding in large part for the utter joy
> of creating a wondrous, living, breathing edifice of code, that works,
> that works cleanly, that works as none has before.  Yes.
> But I would think (IMHO) that the developer would receive a greater
> portion of the ego rush (also a big part of the developer stimulus) of
> overwhelming application acceptance (and thunderous applause), if he or
> she made it easy to support and upgrade!  You see a sysadmin is so often
> an utter coward (I confess), who doesn't like unpleasant surprises,
> whose managment Really Doesn't Like Unpleasant Surprises.  When I do my
> job really well, nobody knows I've done anything.
>
> OK...let me have it.
>
> --
> ====
> Stewart Dean, Unix System Admin, Henderson Computer Resources
> Center of Bard College, Annandale-on-Hudson, New York  12504
> sdean at bard.edu  voice: 845-758-7475, fax: 845-758-7035
>
>