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

[Modestas Vainius]

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.


-- 
Modestas Vainius <modax at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101208/c7b22f3f/attachment-0001.pgp>