Joey Hess said... > Adam Hardy wrote: > > Do apt/dselect and aptitude share the same database as far as the > > currently installed modules are concerned, ignoring whether the packages > > were installed by apt or by aptitude? > > "apt/dpkg/aptitude use different databases" is a frequent statetement on > this mailing list. It's largely a myth. > > dpkg is the underlying layer which is the only thing in Debian that > installs or removes package, and its database about what is installed is > used by all tools. /var/lib/dpkg/status is used by all package > management tools in Debian to keep track of what is installed. dpkg is > the only program that I know of that modifies this file (aside from > dselect possibly, but that's dead), although some others do read it. > > apt uses /var/cache/apt/pkgcache.bin (and srcpkgcache.bin) to store some > additional information beyond what is in dpkg's status file, but this is > notably a _cache_; try deleting the file and watch apt-get update > recreate it from the Release and Packages files it downloads, and from > /var/lib/dpkg/status, with no data loss. It is only used to speed up > apt's access to the information and does not contain any unique data of > its own. > > aptitude is just a frontend to apt and uses the same pkgcache file in > the same way. It also uses /var/lib/aptitude/pkgstates for storing a few > pieces of information that dpkg's status file does not support. This > includes information about whether a package was manually selected or > was installed to satisfy a dependency. IMHO there's no reason why this > information couldn't be rolled back into /var/lib/dpkg/status for use by > other tools eventually. It also includes a way to store state about a > package being held at a particulr version, something that is supported > to a lesser extent by the dpkg status file. > > synaptic, another frontend to apt, uses the same database files as apt > and no others AFAIK. > > All four tools have different approaches for resolving complex > dependency/conflict sutuations, which are much more likely to lead to > differences in behavior.
Thanks a lot for that. Someone lob it in the wiki. -- Best, Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]