Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs
On Tue, Apr 28, 2009 at 03:38:42PM +0100, Roger Leigh wrote: > 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.) Yes. It's very common; imagine program "foo" whose configure script checks for "libbar". When "libbar" is found, it will enable features that depend on it. However, "libbar" is only available in sid and not in stable. > 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? Backporters can do that, but it means more work. If this problem was solved, most backports could be maintained automatically. > I, for example, keep separate debian and debian-backports branches > in a VCS so that such deviations can be easily tracked. It's going to be a branch either way; the difference is between branching the whole thing or just a line in debian/control. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525935: Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs
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 debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525935: Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs
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. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525935: [buildd-tools-devel] Bug#403246: Still occurs
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. In the case of #525935 the fact that the first build-dep is nonexistent will cause problems, and is in itself wrong. You should ensure that the first build-dep is valid. This should be fixed, but unless someone actually works on it and submits patches, it's not a top priority to fix, partly due to the complexity. We are considering implementing alternative dependency resolvers in order to fix the problem, including using a mechanism of a "dependency package" like pbuilder uses so that we use the apt-get or aptitude dependency resolver directly rather than implementing our own. The dependency package is very easy to generate; just a few lines of code. However, I don't yet know of an easy method of robustly triggering package installation and removal or of reversing the process. One can use dpkg --(get|set)-selections to save/restore the packages, but I'm not sure how to synch the real package status to this state reliably (reinstalling missing packages and purging installed build-deps). 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 debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#403246: Still occurs
Hello, Just a quick update to confirm that this bug still exists. See: #525935 Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
