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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
