RPM roadmapping

[David Malcolm]

On Thu, 2007-08-02 at 12:14 -0400, Will Woods wrote:
> On Sat, 2007-07-28 at 21:31 +0300, Panu Matilainen wrote:
> > On Fri, 27 Jul 2007, Dimi Paun wrote:
> > 
> > > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> > >> Or the other way around: what you always
> > >> wished rpm would do for you? What always annoyed you out of your mind?
> > >
> > >  * Version control the meta-information
> > >    This can't be efficiently done outside RPM, and it would provide
> > >    an administrator with an invaluable tool (say a malfunction starts
> > >    at about 4am):
> > >      - what packages changes are different from yesterday?
> > >      - what files have changed for package foo between version V and W?
> > >      - what's the history of package foo on this system?
> > >    Not very difficult, but quite useful. Every time something breaks
> > >    on a system (usually via an automatic yum update) I would kill
> > >    for the ability to run such queries.
> > 
> > Ah, something fresh for a change :) Most of the things that have come up 
> > in this thread, well lets just say I'd been very surprised if they hadn't 
> > come up.
> 
> I know I'm a bit late to the party here but let me second (read: "+1")
> this idea. Having historical rpmdb info would be a huge boon for testing
> as well as sysadmins: being able to show exactly which packages changed
> (and when) would make it easier to implement all kinds of things. 
> 
> Example use case: Over the course of a week, Jake installs 25 new
> packages. He starts up foo-client and it crashes - but it worked when he
> started it last week! Jake wants to get a list of packages that were
> updated in the past week and try rolling some of them back to their
> previous versions.
> 
> Yeah, being able to have a "packages installed/updated in the last N
> days" dialog, with "revert this change" buttons (and love/hate/add
> comment for testing purposes etc.) would be completely awesome.
> 
AFAIK there's no good way to get at this direct from a host's local
data: we have e.g. /var/log/yum.log, but it only records the changes
made via yum; it seems to me like the place for this to live is inside
the rpmdb itself.

There's plenty of complexity in the details here, of course, like
rotating out the logs to stop filling up the disk, etc etc.

The biggest issue: what to store?  one approach might be timestamped
triples of sets of (ENVR, checksum) for packages
installed/uninstalled/upgraded, so you'd do things like this:

rpm -qa --date=2007-04-01
(get list of packages installed at the given time/date; how to express
dates/times?)

rpm -q --changed --from-date=2007-04-01 --to-date=2007-04-31
(get list of packages installed, uninstalled, changed E-V-R within the
date ranges)

rpm -q --changes 
(get list of transactions, handwaving away issues of formatting...)

rpm -q --changes --from-date=2007-04-01 --to-date=2007-04-31
(get list of transactions within the date ranges)

rpm -q --changes --from-date=2007-04-01 --to-date=2007-04-31 glibc
(get list of transactions within the date ranges that affected glibc)

rpm -qf --changes --from-date=2007-04-01 --to-date=2007-04-31 /usr/bin/foo
(get list of transactions affecting the specified file; but this isn't
implementable without storing a much larger amount of data, and similar
for other such queries e.g. 
rpm -q --what-provides --changes --from-date=2007-04-01 --to-date=2007-04-31 some-requirement

[snip]

Hope this helps
Dave