Hello, On antradienis 26 Liepa 2011 22:59:46 Roger Leigh wrote: > On Tue, Jul 26, 2011 at 09:16:17PM +0200, Kurt Roeckx wrote: > > On Tue, Jul 26, 2011 at 09:06:44PM +0300, Modestas Vainius wrote: > > > > I'm not sure what you're trying to say, but we don't use the apt > > > > or aptitude resolvers, we use the internal one. Except for > > > > experimental which uses the aptitude resolver. > > > > > > Backport buildds use aptitude resolver. For example: > > Ok, I didn't know that. I guess it makes sense. > > Both internal and apt lack the intelligence to deal with experimental. > > > > Alternatively, sbuild 0.62.5-1 works well on my system without any > > > further tweaks (because aptitude resolver is smarter). So you can also > > > upgrade sbuild to the later version to fix the problem (this helps > > > since libqtwebkit-dev does not exist in squeeze as per changelog). > > > Still adding "$resolve_alternatives = 1" does not hurt. > > > > If you want to make the buildds use 0.62, someone is going to need > > to put time in it to test that it actually works on the buildds. > > > > I'm also not sure we want to use the aptitude resolver in that > > case. > > We definitely don't. Its major flaw is that (unbelievably) it does > not return a nonzero exit status when it fails, so sbuild does not > know if installing the build deps worked or not. It typically fails > down the line some time after, but it's really unsuitable for building > unstable or anything else given this major flaw. It we can't > determine the build environment was set up correctly, we can't make > any guarantees about the quality of the build. Then check if sbuild-build-depends-packagename-dummy was actually installed after aptitude run and fail if it wasn't? -- Modestas Vainius <modax@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part.