RHEL/CentOS platform is O.K. for me.
Thanks Eric!
--
Constantin IOAJA
Network Administrator C.N.S. Cartel ALFA
On 13.02.2012 19:43, 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: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
