On 06/07/2019 20:03, Mark Rogers wrote:
On Sat, 6 Jul 2019 at 15:13, steve-ALUG@hst.me.uk wrote:
I don't understand the underlying reason why you're trying to do what you're trying to do. What's the top-level reason for wanting to do this
- i.e. what's your initial purpose?
OK, fair question; I have explained some of it above but I'll go into more depth.
I do quite a lot of work on Raspberry Pi's. I back them up periodically as a tarball of the whole filesystem because it's the entire system I'm interested in, not just one or two files.
The result is dozens of tarballs and no easy way to get a simple view of what has changed between them. Changes fall into several categories:
- Mundane updates (apt upgrade etc) - lots of files change but nothing
of substance
- Package installs (apt install xxx) - lots of files get added but can
be summarised by the list of packages installed
- Configuration file changes
- Additions/Changes to my own scripts
Since what I am working with are tarballs, the easiest starting point is the file list; it's trivial to extract the file listing from a tarball and make comparisons between two of them, but when thousands of files can be changed with only a handful of actual changes this is really an exercise in seeing the woods for the trees.
Or consider this example:
- I have a Pi SD card based on Raspbian Jessie and several months of
tweaks and updates (including package additions and removals)
- I want to summarise the changes I've made to I can re-run them on a
clean install (or on Raspbian Buster), using the file listings from a clean install and my working copy as the starting point
Hope that's clearer. Bottom line: What I have is dozens of full OS tarballs that I need to compare, and "installed packages X, Y & Z" is far more useful to me than "added <list of hundreds of new files>".
OK that helps. I don't think it helps the current situation, but I think most people doing something like this would host a git repository to store their scripts & track changes to them. The same idea can be used to cope with changes to configurations for files in /etc/. I'd think it would be easier to keep a manual list of top level packages added/removed using apt-get, than to try and work it out backwards from a file list. I think there are also packages that keep track of installs & config changes so that you can deploy them on other systems, multiple times, but I can't remember the names.
None of that helps with where you are now though!
Searching for "apt installed packages vs dependant packages" provides lots of info, but it pretty much all relies on being run on a live system rather than files in a tarballs.
I did find this though that *may* be helpful.
https://unix.stackexchange.com/questions/381395/how-to-find-which-package-re...
"apt doesn't remember which reverse dependency caused it to install rsync, but it does log all its actions in /var/log/apt, so you might find the dependency there:
zgrep rsync /var/log/apt/history.log*
Look for a line saying that rsync was installed automatically; one of the non-automatic packages there should be the source of the installation."
The pertinent info "apt ... but it does log all its actions in /var/log/apt"
Looking, there's files history.log, history.log.?.gz
and term.log, term.log.?.gz and maybe a few others. History seems to be the top level commands, eg apt-get upgrade, or apt-get install wibble. Term seems to contain the output of the above commands.
<Grandmother suck eggs mode> view .log files using cat history.log
view log.?.gz files using zcat history.log.1.gz
similarly, you can use zgrep to grep a .gz file </Grandmother suck eggs mode>
That may help a bit, but it depends on what period the log-rotated apt log files you have.
It seems to me it would be easier to work out using apt/aptitude etc on a live system - (see the search I mentioned earlier - lots and lots of lovely links, methods etc) It seems to me it would also be easier to keep a manual list of top-level changes.
Anyway, I hope this helps.
Steve