From: Victor Duchovni (no email)
Date: Thu Apr 19 2007 - 17:47:59 EDT
On Thu, Apr 19, 2007 at 11:07:05PM +0200, Simon J Mudd wrote:
> On Thu, Apr 19, 2007 at 03:26:09PM -0400, Victor Duchovni wrote:
> > On Thu, Apr 19, 2007 at 08:53:02PM +0200, Simon J Mudd wrote:
> > > I'd love to work with others to do something like this but the more
> > > generic this becomes the more difficult it is to do well and
> > > understandably Wietse only likes "good code" in his tar balls.
> > Code quality aside, I really don't think that it is appropriate for
> > Postfix to impose its packaging preferences on O/S distributions.
> > Packaging *is* the heart of their job, they do it well, Postfix
> > makes itself easy to be packaged via the postfix-files interface.
> > I think it would be a mistake to bundle code with Postfix that builds
> > packages. However if communities of users for a particular platform
> > construct re-usable packaging scripts, pointers to these can be provided
> > on the add-ons page.
> I think the biggest problem is that normally the "distribution/OS" packages
> tend not to be very up to date, and perhaps not to upgrade within the same version.
> For example:
> RHEL4 uses postfix-2.1
> RHEL5 uses postfix-2.3 (this is only about a month old)
> I'm sure other OSes have similar issues.
> Unfortunately there are a lot of people who need a more recent version
> of Postfix especially because of the spam/virus/... issues and having
> a recent version in a packaged format would help a lot.
> I "help a bit" with RH Linux, but others do a similar job for OpenPKG,
> SuSE, and other OSes. However we all do it differently which means we all
> waste time duplicating pretty much the same work. It's just a shame we
> can't do it once and let everyone use it. Perhaps I'm just too optimistic
> that things like this can be done.
I don't see it as a waste of time, because each distribution rightly or
wrongly needs to make distribution specific changes to integrate the MTA
into their system with appropriate tweaks for SASL, MySQL, TLS, PgSQL,
default paths, good feature patches, bogus patches, ... dependencies,
upgrade logic for previous releases, ...
The common effort is IMHO trivial, platform-specific changes is where I
think all the hard works is. The problem of allowing users to upgrade
ahead of the distribution is complex, and is best solved by pkgsrc,
where the updates are made available centrally to a repository of
multiple consistently managed packages. Generally, it is hard for an
O/S distribution to not blow away user changes when they make a new
Perhaps a common core RPM package for Postfix is a worth-while endeavour,
but I would rather encourage users to press their O/S maintainter for
official updates to specific packages ahead of the next major release.
-- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:?body=unsubscribe%20postfix-users> If my response solves your problem, the best way to thank me is to not send an "it worked, thanks" follow-up. If you must respond, please put "It worked, thanks" in the "Subject" so I can delete these quickly.