David Malcolm wrote:
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.
As long as you are proposing wild changes changes here, why not consider
(optionally) using a real version control system to manage the list of
installed package versions, preferably with the option to use a network
server with many machines appearing as branches. Then you'd commit your
list (and leave it to the version control system to store the
differences efficiently) at any state you might want to recover. You'd
still have to deal with doing everything in the right order to survive a
re-install of some arbitrary number of old packages but you'd always
be able to find what those packages were and you'd have all the VC tools
to view the differences between any points in time - or different
machines if you go the branching route. The bit of magic that falls out
of this scheme is that you'd not only be able to fix a still
sort-of-working machine (as anything relying on the rpm db files could)
but you could reproduce the installation on a different machine or
reconstruct it to an earlier state after a complete meltdown. Of course
having gone this far, I'd want a scheme to also version-control the
local changes to each machine's config files with the same mechanism so
the same tool would show both the installed package differences and the
config differences between any points in time or different machines.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
