[buildd-tools-devel] [GIT] sbuild branch wip/buildd-0.65 created. debian/sbuild-0.65.2-1+buildd3-4-ged90762

[Johannes Schauer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "sbuild".

The branch, wip/buildd-0.65 has been created
        at  ed90762444bd4f5cedd9c009322e217887ea226d (commit)

- Log -----------------------------------------------------------------
commit ed90762444bd4f5cedd9c009322e217887ea226d
Author: Johannes 'josch' Schauer <josch at mister-muffin.de>
Date:   Mon Sep 28 15:39:14 2015 +0200

    lib/Sbuild/AspcudResolver.pm: change aspcud optimization preference
    
    The optimization preference used to be
    
       -new,-removed,-changed,+sum(solution,apt-pin)
    
    But that meant that the first optimization criteria was to minimize the
    number of newly installed packages even if that would mean to remove
    many packages or upgrade many. This can lead to the situation where for
    the sake of finding a solution with the minimal number of new packages,
    even build-essential and fakeroot are uninstalled as they are not part
    of the installation request. Furthemore it can happen that the least new
    packages get installed if some packages get taken from experimental
    while others get upgraded to their versions in experimental which is
    also not desired as we only want to use experimental if absolutely
    necessary.
    
    Setting "+sum(solution,apt-pin)" as the first optimization criteria does
    not help as this would just mean to find a solution that installs as
    many packages as possible from the distribution with the highest pin
    value. But we would rather like a small solution.
    
    The solution is to use the following preference setting:
    
       -removed,-changed,-new,+sum(solution,apt-pin)
    
    Since it is assumed that the chroot only contains a base system and
    build-essential, from which we assume that no package shall be removed,
    we first minimize the number of removed packages. This means that if
    there exist solutions that do not remove any packages, then those will
    be evaluated further. The second optimization criteria is to minimize
    the number of changed packages. This will take care that no packages of
    the base system are unnecessarily upgraded to their versions from
    experimental. It will also avoid any solutions that do need upgrades to
    the experimental versions and keep the upgrades to a minimum if an
    upgrade is strictly required. The third criteria minimizes the number of
    new packages the solution installs. Here it can happen that installing a
    dependency from experimental instead of unstable will lead to less new
    packages. But this should only happen if the package in unstable depends
    on more additional packages compared to the same package in
    experimental. If the solutions are otherwise equal then as the last
    criteria, the number of packages from experimental will be minimized by
    maximizing the sum of the apt-pin values. Since packages from unstable
    have a higher pin value than those in experimental, this should prefer
    packages from unstable except if the solution from unstable is so large
    compared to the one in experimental that their sum of pin values is
    larger in which case the solution in experimental will be preferred.

-----------------------------------------------------------------------


hooks/post-receive
-- 
sbuild