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

[Sean Finney]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20110223/72fa917f/attachment.pgp>