Re: [PATCH] hrmib cache for dpkg
Goswin von Brederlow wrote:
I made a quick port of the "HR-MIB cache" for net-snmp of rpm,
so that it can be used with the dpkg packaging system as well.
...
PS. It can also be used for doing bash-completion of packages.
There are patches for this available elsewhere on the net.
A few points:
1) If the $package.list file already contains all that information for
the current packages in its timestamp then what exactly is the use of
this? Seems more like a log than a cache.
I wanted it to be the same as for rpm, as it would simplify handling:
http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/
agent/mibgroup/host/hr_swinst.c
@@ -183,6 +185,9 @@
#define _PATH_HRSW_directory "/var/db/pkg"
#endif
+#undef _PATH_HRSW_directory
+#define _PATH_HRSW_directory "/var/cache/hrmib"
+
void
init_hr_swinst(void)
{
I think bash-completion currently uses a grep command like:
grep-status -P -e "^$1" -a -FStatus 'install ok installed' -n -s Package
When using the cache, this instead becomes something like:
ls -1 /var/cache/hrmib | sed -ne '/^'$1'/p'
Checking the .list files was the best workaround I could come up with,
as it seemed like "${Installtime}" was not a valid dpkg-query field ?
It's only used for the initial population (if ever), when activated
in dpkg the cache directory is supposed to take care of it itself...
2) If versions are taken without epochs then versions can collide and
they won't work well.
Is it normal to have more than one package of the same name installed ?
I thought it would error on the versions already, let alone the epochs.
But if you do have the same name-version installed more than once then
it would only show up once and removing one might delete the file,
right.
3) Each new version creates a new file. Who cleans up obsolete files?
Or is the "cache" supposed to grow and grow and grow?
If you remove the package, the file is supposed to get deleted too...
(the files are 0 bytes in size, so it doesn't grow by all that much)
It's of course easy enough to just delete the entire directory and
recreate it from the current dpkg package list if anything goes wrong.
4) /var/log/dpkg seems to also alraedy have the info.
It was missing for some packages, and old log files were rotated away ?
But it wasn't a log, more of a exported information directory (cache)
Grepping through the log output is probably worse than grepping status,
which is already twice as slow for bash-completion than checking a file.
--anders
Reply to: