[Dovecot] Dovecot Versions and Debian
If you want to run Dovecot on Debian Lenny for a Production System (with Fast Upgrade System for Security Patches), What would you recommend? Stick to the current port with Dovecot Version 1.0.15 (1:1.0.15-2.3) Use Backports Version 1.1.13 (1:1.1.13-2~bpo50+1)
or Use any of the packages from:
Dovecot v1.1 for Debian Testing (binary and source):
deb http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.1 main deb-src http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.1 main
Dovecot v1.2 for Debian Testing (binary and source):
deb http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.2 main deb-src http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.2 main
Do you find any compelling reason for not using version 1.0.15 ? (Besides of ACL limitations ...)
Regards,
Mario Antonio
Mario Antonio wrote:
As the WIKI states: do *NOT* use these packages for systems that need to be *STABLE*! This is rebuilt every hour from repository commits from Timo and myself and if/when one of us commits a mistake, your setup will break accordingly upon upgrade. This is for testing purposes only.
Regards,
Stephan
Rainer Frey wrote:
I have plans in that direction, but first I need to properly implement the builder as it is now (current scripts are ugly). New features include:
- Has separate scripts for source package composition, package building, and Apt archive management.
- Allows the use of slave builders for Debian releases other than testing or even Ubuntu. Different architectures should be a possibility as well.
- Will automatically incorporate changes from the original Debian package. This is currently triggered manually to prevent problems. Particularly, the Debian-specific patches tend to break against dovecot-head.
- The new composer downloads the official Dovecot tarball releases as a basis (current composer releases a tarball of its own). [done]
- Cleaner Debian packages are built. Unused dpatches are removed and the changelog looks as it is supposed to. [done]
- New/changed compile warnings are reported by e-mail.
I've come a long way already, but I have no real idea when this will be finished. Completing the migration of Sieve/ManageSieve (Pigeonhole) to Dovecot v2.0 currently has priority over the package builder.
Regards,
Stephan
Mario Antonio wrote:
Do you find any compelling reason for not using version 1.0.15 ? (Besides of ACL limitations ...)
It's ancient history. There are far too many improvements to list. The first time you have a question with 1.0.15 we'll tell you to upgrade before you'll get any help. I rebuild the package from sid:
- Download source packages (orig, dsc, and diff files)
- apt-get build-dep <package>
- dpkg-source -x <dsc file>
- cd into directory created by dpkg-source -x
- fakeroot dpkg-buildpackage -uc -b
And it'll make the four dovecot packages.
~Seth
- Seth Mattinen <sethm@rollernet.us>:
Or just grab the excellent source package provided by Stephan Bosch at http://xi.rename-it.nl/debian/pool/dovecot-1.2/ - e.g:
aptitude -y build-dep dovecot (you only need to do that once)
wget -t0 -c http://xi.rename-it.nl/debian/pool/dovecot-1.2/dovecot_1.2.3.orig.tar.gz
http://xi.rename-it.nl/debian/pool/dovecot-1.2/dovecot_1.2.3-0~auto+7.dsc
http://xi.rename-it.nl/debian/pool/dovecot-1.2/dovecot_1.2.3-0~auto+7.diff.g...
dpkg-source -x dovecot_1.2.3-0~auto+7.dsc
cd dovecot-1.2.3
dpkg-buildpackage -rfakeroot
Guess this is the right time for a big "Thank You, Stephan".
Cheers Stefan
Stefan,
In previous emails, Stephan stated: "As the WIKI states: do *NOT* use these packages for systems that need to be *STABLE*! This is rebuilt every hour from repository commits from Timo and myself and if/when one of us commits a mistake, your setup will break accordingly upon upgrade. This is for testing purposes only."
My guess he is just referring to the DEB packages ...
So do you consider safe to use the source package ....?
M.A.
Stefan Förster wrote:
- Mario Antonio <support@webjogger.net>:
Of course this is safe. Just kidding.
If you want to compile these source packages, take _one_ version, compile it and then test it thoroughly. If it passes all testing, then put it into staging, test more, and only if it passes all test again, move it to production environment.
And don't upgrade every time a new source package is available.
As always, you should know what you are doing if you install packages provided by third parties, be it binaries or sources you compile yourself. Example: The sources come with a "2:" epoch. If one day, the next stable version of Debian comes with "1:1.2.8" and you previously installed your freshly built "2:1.2.1", then the upgrade process will not replace your old, outdated, built-from-source packages.
Cheers Stefan
participants (5)
-
Mario Antonio
-
Rainer Frey
-
Seth Mattinen
-
Stefan Förster
-
Stephan Bosch