Getting the the dependency tree data is not all that difficult as it can be done with a list of packages, dpkg -L, and some text processing pipelines; however, there is probably a tool out there already. There is also some logic involved with regard to the fact that a dependency can be satisfied by 1 package or another. What I was thinking was you simply make a list of packages and dependencies and if a package is installed that is not on the list you remove it, if a package is not installed you install it.
--- On Sat, 12/13/08, Henning Sprang <[email protected]> wrote: From: Henning Sprang <[email protected]> Subject: Re: Purging unlisted packages To: "linux-fai" <[email protected]> Date: Saturday, December 13, 2008, 3:21 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Tautschnig wrote: > I guess we could try to get the list of all depends and then use Holger's > suggestion about the very simple diff-approach. The problem is not the diffing, but getting the proper list... But you're right, it might work with libapt-pkg-perl. Maybe it also works with something as simple as feeding the list of explicit packages into apt-get install with the no-action option?! (and aptitude and others that are possible with PACKAGES lists) > Well, and that list of depends > we could maybe get from libapt-pkg-perl (hopefully). If the latter is the case, > it's really not that hard. It might be less than a week, but more than a day of work... > Who on the list is familiar with that perl package? > And well, it would also be cool for FAI-installed systems, because changing > package lists may result in packages on your system that you don't need anymore. Removing classes, too. It's not as much a bad idea as Thomas said, that's why I wrote I disagree with him. The next step would be to track changes made by classes, to reverse-patch changed files, to get some sort of "undo" function, to really remove changes made by classes. I had a presentation with a potential customer who asked for this - even more, for the ability to go back to a specific state - or at least one step back like "before the last softupdate" - even better "before the last three softwupdates" or "state of 2008-10-22"... interestintg things, but here we are really talking rather weeks than days of work. It would be cool to have these things - let's find somebody to implement it :) By the way, anwother interesting project that seems to deal with the difference between the ideal that one only has exactly configured system only changed by the config management system, versus the reality that somtimes fast manual changes are necessary(in an emergency, as well as in development of some configuration, you cannot always run the system for every little change) is this one: http://cft.et.redhat.com/ Henning - -- Henning Sprang http://www.sprang.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJRBkyOzXGJHJLmQIRAsMJAKCEZY5d+iaDRPRl3mc6WJH5cT50vwCghbfW kKiXda2WW8+enYH3mPvmCeU= =/taB -----END PGP SIGNATURE-----
