FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-22-2011, 10:17 PM
Sean Finney
 
Default Bug#614413: re buildd's resolver and package's build deps

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
 

Thread Tools




All times are GMT. The time now is 10:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org