Hi, I was just writing a bug report on the new nautilus, looking in dpkg.log to know what version I had before the upgrade, and then I got wondering if that wouldn't be an interesting information to have by default in bug reports, for both the package the user reports the bug against, and all its dependencies, indicating both the previous version and when the upgrade happened. If space is considered a problem, I'd say this information could replace the packages descriptions, which are IMHO pretty useless to the package maintainers. What do you think? Mike
Hi Mike, ok, I know, it's a rather old report... :) I'm just wondering... by default dpkg.log is rotated monthly, so if you're so unlucky to install the package on 31st and report the bug on 1st of the next month you don't get any information, if not searching in all the rotated files, which then required maybe to go back in time a long ago, and so also to report the date of the upgrade, and so on also, there are several cases where the upgrade information (if available) is useless, f.e. in reports like "documentation for function aaa() is missing". I understand it can be nice to have that info in some circumstances, but I don't see a way to balance that with an over-complicated solutions. any ideas? cheers,
Maybe a helper that the maintainer could ask the bug reporter to run. I sometimes as them to run reportbug --template $somepackage, that could be something similar. Mike
mh, that would be nice! but do you think that's something up to reportbug to provide, or more fittingly something dpkg can ship?
I really don't have a preference. Mike
clone 548415 -1 reassign -1 dpkg retitle -1 please provide a tool to parse dpkg.log* files block 548415 by -1 thanks Ok, so I clone this bug to ask dpkg maintainer to provide a tool to parse dpkg.log* files. for example it would be cool to have an option to have the last upgrade of a package like <date> <previous version> <upgrade version> and probably a list of all the "relevant" events of a given package (f.e., install, remove, reinstall, purge, etc etc). Mike something I'm missing here? Cheers,
Hi, I don't think we're going to ship anything like this in the near future. But Enrico Zini was interested in adding this information in the apt-xapian-index database. We have added a feature in the master branch so that he can get the status information in real time. Maybe you could reuse the information stored there once it's implemented? Ccing Enrico so that he can comment too. Cheers,
Except if we make all users have apt-xapian-index installed, this is not going to be helpful to maintainers. Mike
It's a recommends of aptitude and is installed by default. Cheers,
yet. I'd consider it entirely reasonable to use the data extracted with this dpkg hook into some data file independent from apt-xapian-index. In fact, the index itself should not be used as a primary data store, as it should be possible to delete it and recreate it without loss of information. For this reason, since the upgrade information is extracted incrementally from the hook, it needs to be collected outside of the index, like we currently do with the cataloged_times plugin: /var/lib/apt-xapian-index/cataloged_times.p. We should work out how this storage should be: - a flat file is not efficient when the operation is "updating only one value of only one package". - A log file keeps growing. - If you don't want apt-xapian-index as a dependency, then I imagine you want to keep the number of dependencies as small as possible: a sqlite3 file maybe? Some simple key-value store à-la gdbm? Ciao, Enrico
I, for one, don't care very much about the dependency, but more about the fact that not having it installed could mean not being able to pull the information, even by installing afterwards. A dpkg.log parser would always work, except when the logs are rotated and old enough to have been removed. Mike
I tend to agree with Mike here: a log parser would be very nice, like something dpkg-log last_ops <package> <N> <op_N, like purge install remove etc> <package> <version> <N-1> <op_N-1> <package> <version> (<prev_version> if needed) <N-2> <op_N-2> <package> <version> <N-3> <op_N-3> <package> <version> <N-4> <op_N-4> <package> <version> or a series of other interesting commands. Default logrotate configuration keeps a year of log, so we have quite a bit of room even for the very lazy bug reporters :) What I'd like to avoid (with the reportbug maint hat on) is to let reportbug parse a log file (either dpkg or xapian) to extract the info it needs. Cheers,
Looks like things are happening http://justimho.blogspot.com/2011/02/let-me-introduce-dpkglog-and-dpkg.html Mike
Sorry to chime in so late; I've reported some bugs against libdpkg-log-perl, let's see how it goes. If I missed some, please integrated :) Regards,