<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.<BR><BR>--- On <B>Sat, 12/13/08, Henning Sprang <I><henning@sprang.de></I></B> wrote:<BR></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid">From: Henning Sprang <henning@sprang.de><BR>Subject: Re: Purging unlisted packages<BR>To: "linux-fai" <linux-fai@uni-koeln.de><BR>Date: Saturday, December 13, 2008, 3:21 PM<BR><BR><PRE>-----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-----
</PRE></BLOCKQUOTE></td></tr></table><br>