Good call. I've been using the CentOS/QMT combination since 2005 and
wouldn't think of any other.
On 2/13/2012 10:43 AM, Eric Shubert wrote:
> I've done a good deal of thinking about this, and think that it'd be
> best to run it by the community at large (not just the developers) for
> everyone's consideration. This is not really new, and is not much
> different than what Jake had committed to some time ago. I just want
> to be sure that everyone is on board with this, and explain a few things.
>
> Due to various changes in the IT landscape over the past several
> years, I think it's best that future QMT development be limited to the
> RHEL/CentOS platform. There are several factors involved.
>
> First is that we'll be changing the method of distribution from source
> rpms to binary rpms, using yum to install packages (qtp-newmodel will
> be modified accordingly). We can do this because the qmail (et al)
> licensing was changed to public domain a couple years ago, so there is
> no restriction to distribute source-only any more. We also have
> mirrors in place that eliminate the need to have a single distribution
> point with high bandwidth capability. Using binary rpms for
> distribution not only simplifies installs and upgrades, but it also
> substantially reduces the disk space required, in addition to making
> QMT more secure due to the absence of a compiler and build tools. All
> in all, this is a win-win change.
>
> Secondly, the industry in general is moving toward virtual hosts, and
> QMT is making this move as well (many of us already run QMT as one or
> more VM guests). One of the advantages of virtualization is that
> multiple machines can coexist on the same host hardware, concurrently
> running entirely different operating systems and versions of languages
> and software. There's little need any more for QMT to coexist on the
> same machine with other applications or services. In fact, things are
> moving in a direction such that QMT itself will become divided into
> logical roles that will be able to implemented on separate hosts,
> allowing for more flexible and scalable QMT configurations. Stay tuned
> for that development, which is a ways off yet.
>
> So let's take a look briefly at the prominent distros that QMT will be
> discontinuing.
>
> Mandriva is on the ropes, struggling to survive. If you presently have
> a QMT running on Mandy, I would seriously consider a migration in the
> near future.
>
> SUSE does not use yum, it has yast instead. When I looked at yast some
> time ago it had no CLI, which was a big drawback to me. While I expect
> that yum could be installed and used, it goes against the "When in
> Rome" philosophy. The source rpms will of course continue to be
> available, so if someone cares to adapt them for SUSE, they may do so.
>
> While Fedora contains a great deal of what's in store for future
> RHEL/CentOS releases, it's not well suited as a QMT platform, simply
> because it changes too often (a new release twice a year), and most
> often none of the changes provide any benefit to QMT. If there happens
> to be something that would benefit QMT, it would most likely be
> available for RHEL/CentOS in the EPEL repo. So there is really no
> sense in packaging QMT for Fedora.
>
> I think this covers the distros worth mentioning. If I missed one,
> please let me know.
>
> In summary, going forward QMT will be available only on RHEL/CentOS
> platforms, for both x86 and x86_64 architectures. This will simplify
> spec files, documentation and installation/utility scripts
> substantially. For all other distros, the existing build options in
> the spec files will no longer be included. They will however be
> archived in a source code repository before being removed, so that
> they'll be available should anyone want to reference them at some
> point in the future.
>
> If you have a problem with or question about any of this, or you'd
> simply like to comment about something, please don't hesitate to reply.
>
> Thanks to everyone for their continued support and participation.
>
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
