[php-maint] Bug#614413: Bug#614413: Bug#614413: re buildd's resolver and package's build deps

[Ondřej Surý]

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 <seanius at debian.org> 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
> pkg-php-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
>



-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/