[buildd-tools-devel] Bug#606278: Bug#606278: Bug#606278: Bug#606278: aptitude resolver is completely broken in 0.60.6

[Andres Mejia]

On Wed, Dec 8, 2010 at 2:19 PM, Modestas Vainius <modax at debian.org> wrote:
> Hello,
>
> On trečiadienis 08 Gruodis 2010 13:06:23 Roger Leigh wrote:
>> > > Ok, the latter is because you removed a key option (that I added some
>> > > time ago) from aptitude command line in
>> > > 80f811184d7c7b06a6a5ec8d646b1eac015dffa2. That's:
>> > >
>> > > '-o', "Aptitude::ProblemResolver::Hints::KeepDummy=reject
>> > > $dummy_pkg_name
>> > >
>> > > :UNINST",
>> >
>> > I removed this because it no longer seemed necessary when installing
>> > the package directly from a local archive.  It shouldn't be a
>> > candidate for removal if we explicitly asked for its installation?
>>
>> The patch I attached in my other mail should solve all the other
>> issues.
>>
>> - dummy packages are created correctly
>> - local archive created correctly
>> - archive signing key created correctly
>> - archive signed correctly
>> - dummy packages install from archive correctly
>>
>> I'll add back the above aptitude option if it's still required, but if
>> you could test the attached patch and let me know if there are any
>> remaining problems, that would be great.
>
> /tmp is fixed and sbuild now tells me when it is generating a key (which is
> good). But now I have another nitpick. The new way of installing dependencies
> means that `apt-get update` is run twice (once for core-dummy and once for
> package-dummy). This might not be always desirable (e.g. when rebuilding the
> package repeatedly from the same aptcache). Also, --apt-update option became
> redundant, didn't it?
>
>> If you still find this option
>> is required for correct functioning, I'll add it back.
>
> It is necessary, see below.
>
>> It shouldn't be a
>> candidate for removal if we explicitly asked for its installation?
>
> No, that's not the case. A mere fact that a package is a candidate for
> installation does not mean that it will end up being installed, e.g. it might
> be impossible to install the package due to conflicts. All needed info can be
> found in [1] and [2] (from aptitude-doc-en package).
>
> I will explain current approach in AptitudeResolver. As you can see from
> aptitude docs, by default Non-Default-Level is very unsafe. So aptitude will
> always prefer to remove the package we want to install if it depends on
> packages from non-default repositories. Bumping safety of Non-Default-Level is
> dangerous because aptitude may start installing packages from non-default
> repos (experimental) when there is a good enough version in the default repo
> (unstable). So keeping Safe-Level, Remove-Level etc. at their safe defaults is
> desirable. All we need is to tell aptitude to ignore/exclude all solutions
> which involve removal of the dummy package even if they were "safer" because
> they definitely won't satisfy us. That's what that KeepDummy hint does. So
> aptitude ends up giving us the *safest* solution which does exactly what we
> want (i.e. installs dummy package).
>
> [1] file:///usr/share/doc/aptitude/html/en/ch02s03s04.html
> [2] file:///usr/share/doc/aptitude/html/en/ch02s03s05.html
>
> P.S. As I see now, aptitude 0.6.3 dependency resolver is even more
> configurable than the one from aptitude 0.6 when I originally wrote the first
> patch. So it might be possible to think of better SolutionCost algorithm for
> sbuild needs. On the other hand, current one has not disappointed me yet.

This looks like a matter of aptitude and apt being different. I think
in order to get somewhat the same behavior as apt, aptitude should be
passed the '-o "Aptitude::ProblemResolver::Hints::KeepDummy=reject
$dummy_pkg_name :UNINST"' option.

> --
> Modestas Vainius <modax at debian.org>
>
> _______________________________________________
> Buildd-tools-devel mailing list
> Buildd-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/buildd-tools-devel
>



-- 
Regards,
Andres Mejia