Re: Using apt-file db to find possible conflicts
From: Ralf Treinen <email@example.com>
Subject: Re: Using apt-file db to find possible conflicts
Date: Fri, 21 Mar 2008 09:27:31 +0100
> On Thu, Mar 20, 2008 at 11:16:39PM -0400, Matthew Rosewarne wrote:
> > On Thursday 20 March 2008, Sami Liedes wrote:
> > > I don't know if there's any previous work on this, but since I as a
> > > sid user often see conflicts in packages, and I've seen those on
> > > numerous oldstable->stable upgrades, I thought something could be done
> > > about it. Actually, most often oldstable->stable updates seem to me to
> > > have been more like iterative processes, rerun dist-upgrade until no
> > > errors.
> > >
> > > So I wrote a script to get a list of packages with identically
> > > named files from the apt-file database and to run `apt-get --dry-run
> > > install' for each pair of these potentially conflicting packages to
> > > see if apt can find a way to install both of them at the same time.
> > Oddly enough, I just whipped up a similar script  for finding conflicts
> > between kde3 and kde4 packages. Instead of finding any conflicts between all
> > packages in a Contents-*.gz file, it finds any conflicts between a single
> > package and the any of the available apt-file lists. It's quite stupid as it
> > doesn't bother to check for existing Conflicts or Replaces entries, and it
> > uses apt-file VERY inefficiently.
> > Perhaps these two scripts could be combined into something genuinely useful.
> me too :-) I did something similar some time ago, but using a different
> approach for testing co-installability: the edos tools. The difference
> is that this tells you whether it is possible to install by a series
> of manually guided installations the two packages. This might be the
> case even if an "apt-get install" query to install the two packages
> simultanously doesn't find it. OTOH this is still a "local" test
> specific to one distribution, it does not address the problem of
> upgrading from an earlier state (dist-upgrading from stable, or partially
> upgrading some of the packages).
> As it has been said by Matthew: the missing piece is to properly handle
> diversions. If you are interested to setup a small project to solve
> this I'm in.
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Since there is so much work on this I'd like to propose to use this
tool to solve another problem. I like to install lots of software on
one system but often times packages cannot be installed simultaneously
because they depend on conflicting packages. I would like some way to
visualize this for the whole collection, to see which packages
conflict. Some classification system for conflicts should be made
(like essential, removable, etc.) and then we'd know where to apply
our efforts. This wasn't a very good description of the tool, but in
general it would be nice to visualize, reason with the mathematical
object that is the depends/conflicts graph.