On Tue, Apr 28, 2009 at 04:05:09PM +0200, Robert Millan wrote: > On Tue, Apr 28, 2009 at 01:24:26PM +0100, Roger Leigh wrote: > > On Tue, Apr 28, 2009 at 02:03:10PM +0200, Sylvestre Ledru wrote: > > > > > Just a quick update to confirm that this bug still exists. See: #525935 > > > > Thanks. We still haven't yet had any proposed patches to the > > dependency resolver to correctly support alternative build dependencies. > > Currently support is extremely poor. This is partly because the > > whole idea of alternative build-deps would result in non-deterministic > > builds. > > Perhaps a solution would be for packages to specify two Build-Depends fields: > > A- One that defines which dependencies are essential for build to work > > B- One that defines which dependencies are expected to be present in > official builds > > Then maintainers and buildds must satisfy B, while backporters can satisfy > A and try to satisfy as much as possible from B.
I'm not sure that a separate type of Build-Depends field in the control file is necessary. Surely a build dependency is required or not required; there isn't really a case in between where it /might/ be required, is there? (Excluding arch-specific, which is already catered for.) Should backporters not simply alter the build-depends to be correct in the backport environment, and/or backport any needed dependencies if they can't be satisfied by older packages? I, for example, keep separate debian and debian-backports branches in a VCS so that such deviations can be easily tracked. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
