tags 608789 + fixed-upstream pending thanks On Mon, Jan 03, 2011 at 03:28:18PM +0200, Modestas Vainius wrote: > Package: sbuild > Version: 0.60.8-1 > Severity: normal > Tags: patch > > Hello, > > I partially take my words that I said in [1] back. aptitude sometimes needs a > bit more hints to give us what we really want, i.e. we need to feed it a > custom > SolutionCost as default settings might not be sufficient for experimental, > backports and especially more complex buildd configurations. > > Issues concern installation from non-default sources. You will find full > explanation in the patch header. Please keep commit message intact (if > possible) as it contains useful information on the "how aptitude resolver > works" topic.
Thanks, I've applied it with "git am -s" which has kept the full log message and authorship intact. I'm not an aptitude expert, but your detailed explanation looks logical and sensible, and checking the aptitude documentation it all looks good. Regarding my other mail you referenced. There's quite a lot of speculation and misinformation about whether apt and aptitude will behave the same, behave sensibly and predicatably etc. With regard to using either as the default resolver in sbuild, what we really need is some /empirical/ data to practically demonstrate how each behaves then we can actually make a rational decision about which should be used. I think what I'd like to do here is create a set of dummy packages in the same manner as used to install dependencies (we can reuse the code), and then we can get both apt and aptitude to install them in various different chroot environments (minimal, dirty, containing build-conflicts, containing different alternative virtual packages, etc.) and then we can directly compare their behaviour and tweak them if necessary. Such a facility would also be good for testcases we can add to sbuild to verify the resolvers are working correctly; the difficulty here is a stable baseline distribution to use which won't change; stable is probably the best bet, but won't allow testing of experimental since it's moving too fast. Many thanks, 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.
signature.asc
Description: Digital signature