[buildd-tools-devel] apt-get option to keep dummy packages

[Roger Leigh]

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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101118/1e0ae3f1/attachment.pgp>