Propose exim4 for debian-volatile (Was: exim4_4.50-8sarge1)
[ CC'ing debian-devel, as more people might catch it up there ]
On Thursday, 02 Mar 2006, Andreas Barth wrote:
> 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
> 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
> 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
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]