On Thu, Nov 18, 2010 at 09:14:48AM -0500, Andres Mejia wrote: > On Thursday 18 November 2010 05:29:22 David Kalnischkies wrote: > > On Wed, Nov 17, 2010 at 19:55, Andres Mejia <mcitadel@gmail.com> wrote: > > > I'm helping out with testing the new apt resolver used in the latest > > > sbuild in unstable. Question I have is, is there some option or set of > > > options that will cause apt-get to refuse to remove a package or maybe a > > > set of packages. For example, aptitude has this option. > > > > > > -o Aptitude::ProblemResolver::Hints::KeepDummy=reject <dummy_package> > > > :UNINST > > > > > > This means aptitude won't accept a solution where the <dummy_package> > > > will be uninstalled. > > > > A similar thing could be implemented easily in pkgDepCache::IsDeleteOk, but > > if your command is really an 'apt-get install whatever' apt should never > > accept a solution in which whatever is not installed. It will either fail > > bigtime (if it is really impossible to install) or provide even an insane > > solution (remove half of the system, for example). > > > > > > I would try to avoid using special hints for the resolver as a user never > > would give such hints, so you might hide problems a user would encounter > > without these hints and after all, what does it help if sbuild can build a > > package if a random user can't do it? > > > > I mean, what does it help to have a package installed which is broken? > > The check if is broken or if it is installed at all doesn't look to > > different an either way is a build failure… > > The way the apt and aptitude resolvers work in sbuild is that a dummy package > is created which has all Build-Depends and Build-Conflicts listed as Depends > and Conflicts for the dummy package. This dummy package is then forced to be > installed using 'dpkg --force-depends --force-conflicts'. Afterwards, at least > in the case with apt, an 'apt-get -yf install' is run to resolve system > dependencies. The result that's expected is that all build dependencies are > installed. > > What happens in some situations is that apt removes the dummy package instead. > We want apt-get to refuse to give a solution resulting in the dummy package > being removed. I'd just like to add that, while we are currently going with the "dummy dependency package" approach to get apt-get to install/remove depends/conflicts, we're open to alternative approaches. The actual requirement is to - install a list of build-depends - remove a list of build-conflicts - ideally in a single operation. This isn't just a list of packages; it also includes versioned dependencies and alternative dependencies, so what we want to provide to apt-get is basically what you'd have in a Depends: and Conflicts: field and get it to resolve them. Installing a dummy package is the current approach to getting this information to apt-get, but there may be better ways. Getting apt-get to install the local package and resolve the deps in a single operation, rather than involving dpkg would be an option, but setting up a local repo is not to easy, considering the need for everything to be signed, but it's something to consider if a feasible approach. Another requirement not mentioned above that apt and aptitude both currently fail on is the need to resolve alternative and virtual dependencies /predictably/. That is, we could like it to consider the alternatives in a left-to-right order, picking the first that can be satisfied, rather than treating all alternatives equally. This is to ensure dependencies are resolved in a predictable manner for each build on all architectures. Virtual dependencies are a bit harder; we currently just pick the first alphabetically--the rule it uses isn't too important, so long as it's totally consistent. Regards, 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.
Attachment:
signature.asc
Description: Digital signature