hi, On Mon, 2011-02-21 at 19:42 -0600, Raphael Geissert wrote: > I disagree here. > Alternatives in build-* relationships *are* mentioned by policy. In fact, > there's even an example in section 7.1. > > There's also no stated guarantee *anywhere* (including release policy) that > the package's build deps should be consistent, much less the result. > > Also, alternatives have been used ever since I joined the project for making > backporting easier. Requiring stricter build-deps also affects that use case. for the record, full ACK on raphael's statements (maybe the PHP packages could use a bit of cleanup there post-squeeze-release though, but that'd be severity: wishlist). > After thinking about it for a while, my opinion is that if anyone wants > consistency to be guaranteed (e.g. in php's case that a rebuild doesn't end up > linking php to libdb4.6 instead of libdb4.8) it should be handled on > buildd/release team's side. The build deps as provided by the source package > are valid. and we need *some* kind of predictable way to determine how they're resolved for specifically that reason. in the case of libdb, this is actually pretty significant because other libdb-linking apps link to php stuff (like, say, apache + apr + libapache-mod-php5), and we want everything using the same version. i would assume that "first given should be default" should be reasonable enough, and on the rare chance that something breaks, we get it handled with a binNMU or subsequent upload. i think the backport branching argument from roger is valid in the hypothetical sense, but i think there's a number of maintainers who support backporting only to the point that someone else is doing it and all they have to do is add some alternate build-deps, and they probably wouldn't bother otherwise. in the case of php, for example, i would hurl expletives at anyone who suggested that we start supporting yet another branch (and subsequently ask them if they were interested in "joining" pkg-php, muwahaha) backwards-compatible can also mean forwards-compatible too, which i suppose might make a package binNMU'able in some kind of transition where it would otherwise be needing a sourceful upload. anyway, just my 0.02 $LC_MONETARY fwiw :) sean
Attachment:
signature.asc
Description: This is a digitally signed message part