• Software

  • Presenting apt-history, a Linux utility

Johnaudi wroteWhat a nerd, I love it.
I was thinking the same. It is amazing how we take time to write utilities to make our computer management easier. I've written quite a few utilities in Vala, C, and C++ for this particular purpose.

Nice work, @rolf.
Thanks. I find it a bit useful.
I also enjoyed working on this little project.

@VincentKeyboard Sounds interesting. I would be curious to see. I encourage you to release a few - let us know if you do please.
Sure, I'll push a few to a github account. Most of this was out of necessity on Linux.
Really cool Rolf. I can see the ability of referring to packages as digits in a history file being pretty useful.
Nice.
Thank you. Yes the numbering is simple and convenient.
I have a concern though, that logrotate would swich out history.log between two commands, in which case the number will then be referring to something else.
If this happens, the fresh history.log would probably be an empty file, which would limit the potential for damage.
Cant you just type for example apt-get install xxx >> output.file and when you can just check that file or i understood your solution wrongly ?
potato wroteCant you just type for example apt-get install xxx >> output.file and when you can just check that file or i understood your solution wrongly ?
That is not how it is supposed to be used.

There is an APT logfile in /var/log/apt/history.log - maybe have a look at it.
When you do `apt-get install` (or other APT operations), it records an entry in the log file, including details.
You can have a look at the log file, maybe using cat, tail, grep, etc.
Or you can use this tool (apt-history).
You can have a look at the log file, maybe using cat, tail, grep, etc.
The issue is that the log file is in a complex format and parsing it can be a pain. grep and such make it difficult to deal with it. A tool like `apt-history` would allow this.
I have a concern though, that logrotate would swich out history.log between two commands, in which case the number will then be referring to something else.
This is a real problem. One thing you could do, if you package it as a .deb, is to include a postinstall script to disable log rotation for this file. I'm not too sure how to do it, or if it's even a good idea.
pacman doesn't rotate its history file (pacman.log) but that is widely regarded as a bad idea.

Correct me if I am wrong here please but if an application A is reading from history.log and the log file is renamed to history.log.1 (while application A still has history.log open) and a new history.log is created, isn't application A still reading from old history.log thus creating an orphaned inode containing the old history.log till application A is closed upon which the orphaned inode is cleared?
@VincentKeyboar, it could happen. Or something else might happen. It depends on your config, and there's about a million different thing that could impact it.

The proper way to do it is to use a locking mechanism so that nothing touches history.log as long as apt-history is accessing it. Which might be a pain to do without having to modify apt first.
@Joe, I was thinking of ext4. it is explained here https://unix.stackexchange.com/questions/290116/what-is-an-orphaned-inode
In reality, binary loggers and databases cannot handle orphaned inodes but plain text ones can still read them till fclosing them.
type tune2fs -l /dev/yourext4partition and look for the number of orphaned inodes.

To test, get two files movie1.mpg and movie2.mpg. Open movie1.mpg in mpv and delete it. Rename movie2.mpg to movie1.mpg. mpv still play the old file till it exits.

The locking would have to be in both logrotate (somehow) and apt-history as both can attempt to open the same file simultaneously.
I'm interested in testing this out, but I don't have an ext4 partition available here.

I'll run it on different file systems and update my results asap.
It's basically how you can update from gtk 3.24.5 to 3.24.6 without closing any currently open gnome/gtk applications since they are still using the old version of the libraries even though the package manager "deleted" them. Only newly opened applications will be using 3.24.6
Other file systems may behave the same. It may even be a feature at a lower level as well. But I can't claim any information that I haven't tested myself.
This script is not persistent, so you would you run it once to get a list of transaction, then you run it again to get a detail about a transaction, using an ID number from the previous list. So don't think any locking can be applied.

Some possible solutions:
- Re-think IDs. Maybe use timestamps instead, for example.
- Add persistent storage to the script and keep track of the timestamps on history.log, so that a log rotation is detected

In practice I am not too worried because if the log gets rotated it will most probably become empty and running any query with apt-history on an empty log will just return nothing which should not cause any damage - only confusion.

However this is something to keep in mind and if this gets further developed, this issue should be high on the list of priorities.
Joe wrote This is a real problem. One thing you could do, if you package it as a .deb, is to include a postinstall script to disable log rotation for this file. I'm not too sure how to do it, or if it's even a good idea.
I would not want to modify the system.

Do you think it would be a good idea to package it as .deb? I am using using npm at the moment, which does the job.

Thank you for your interest and suggestions by the way!