Propose exim4 for debian-volatile (Was: exim4_4.50-8sarge1)

[Martin Zobel-Helas <zobel@ftbfs.de>]

Hi,

[ CC'ing debian-devel, as more people might catch it up there ]

On Thursday, 02 Mar 2006, Andreas Barth wrote:
> Hi,
> 
> I propose to accept exim4_4.50-8sarge1 into volatile. This version is
> already accepted into the next point release, and I would put the
> binary-idential packages into volatile.

so why put it into volatile if it will be included into the next stable
point release?

> The change fixes one problem that became more and more problematic with
> the more and more widener deployment of ipv6 - if only some addresses
> are in the additional section of the answer of the query for the
> mx-record, only those addresses are tried. Especially, if only ipv6
> addresses are there, but no ipv4 ones, and the host doesn't have ipv6,
> the mail may be delayed or even bounce. The patch just ignores these
> additional sections now, and always asks for all addresses by an extra
> dns query.

True, this has been reported several times on the debian-devel mailing
list.

> I think it matches into volatile, as:
> |  acceptance rules
> 
> |   * volatile is not "just another place" for backports, but should
> |     only contain changes to stable programs that are necessary to keep
> |     them functional;
> the new version contains exactly one changeset. This changeset is
> necessary to keep exim4 operational towards hosts having ipv4 and ipv6
> records. As more and more hosts get ipv6 records, this is necessary.
> (Basically like the newer postgrey daemon - no protocol changes, just
> the whitelist increased as the maintainer knows now more hosts that need
> to be in that list.)

yeah, but the postgrey whitelist contains so called "volatile data"
which i can't find in exim4.

> |   * It should allow any administrator to "just use" volatile, as they
> |     "just use" security.d.o, and they should be confident that nothing
> |     is broken by that;
> 
> yes, done. As it is part of the next point release, that already needs
> to be ensured.
> 
> |   * the upgrade path from volatile to the next stable release needs to
> |     be at least as easy as from the current stable release; means e.g.
> |     that the version in volatile must not be higher than in testing
> 
> same. (I deleted some items, which are trivially also ok.)


I don't see any reason accepting packages into debian-volatile, when
they contain no volatile data. Also if the package will be in the next
stable point-release i don't see any reason why to put it into
volatile...

Just to have it in an archive earlier than in the next point-release?
Sorry, i don't count that as a reason.

I currently disagree with that proposal, but will accpet it if a) the
users want to have it into volatile and/or b) if you can convince me
that it makes sense to have it in volatile. Thus i ask you folks (on
debian-devel) to give more input on that.

[ removed the patch, can be found in previous mail in the archives]

Greetings
Martin