[buildd-tools-devel] Bug#608789: Bug#608789: custom SolutionCost for AptitudeResolver in order to improve results

[Roger Leigh]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110103/5fb8102f/attachment.pgp>