[Reportbug-maint] Bug#548415: reportbug: Package upgrade information in bug reports

[Mike Hommey]

On Thu, Jan 06, 2011 at 12:28:32PM +0800, Enrico Zini wrote:
> On Wed, Jan 05, 2011 at 09:08:22AM +0100, Mike Hommey wrote:
> 
> > > 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.
> > 
> > Except if we make all users have apt-xapian-index installed, this is not
> > going to be helpful to maintainers.
> 
> I haven't implemented anything on the apt-xapian-index side of things
> 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?

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