On Wed, Dec 8, 2010 at 2:19 PM, Modestas Vainius <mo...@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 <mo...@debian.org> > > _______________________________________________ > Buildd-tools-devel mailing list > buildd-tools-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/buildd-tools-devel > -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org