tags 614413 +wontfix thank you Hi,
just to reconfirm our position - I'm here with Sean and Raphael. (And BTW: Roger, very good work on that report, we just don't agree with the conclusion ;)). Ondrej On Wed, Feb 23, 2011 at 00:17, Sean Finney <[email protected]> wrote: > 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 > > _______________________________________________ > pkg-php-maint mailing list > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint > -- Ondřej Surý <[email protected]> http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
