Re: synthesizing yum transactions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, Nov 05, 2015 at 11:39:41AM -0500, Brian Reichert wrote:
> So, given the knowledge of what RPMs are currently installed, is
> there a way to invent a new transaction incorporating them, without
> reinstalling the RPMs in question?
> 
> I feel I've come close, with this methodology, basically coercing
> yum to rebuild a database in a private directory:

So, I'm closer, but I'm getting a new symptom.  My test setup:

First: to replicate the effect of not using yum consistently:

Install server from CentOS-6.7-x86_64-minimal.iso

Install repoquery, etc.:

	yum -y install yum-utils rsync

Install GCC and dependencies, but do so with the rpm utility:

	yum --setopt=keepcache=1 --downloadonly -y install gcc
	find /var/cache/yum/ -name \*.rpm | xargs rpm -U

This has the side effect of updating glibc, but yum doesn't have a
transaction related to that:

	[root@localhost ~]# rpm -q glibc
	glibc-2.12-1.166.el6_7.3.x86_64
	[root@localhost ~]# yum history package glibc
	Loaded plugins: fastestmirror
	ID     | Action(s)      | Package
	---------------------------------------------------------
		 1 | Install        | glibc-2.12-1.166.el6.x86_64
	Warning: RPMDB altered outside of yum.
	history package

The question is: how can I invent an additonal yum transaction such
that I can roll back to tid 1?

This looks like it works, up to a point, in terms of creating a new
transaction:

	workdir=/home/yum-hack
	rm -rf ${workdir}
	mkdir -p ${workdir}
	cd ${workdir}
	
	# Dup repos and rpm/yum databases
	for tree in /var/lib/rpm/ /var/cache/yum/ /var/lib/yum/ /etc/yum.repos.d/;
	do
  	  mkdir -p ./${tree}
  	  cp -pr ${tree}/* ./${tree}
	done

	# Reinstall new RPMs, via yum, in private work directory
	# Avoid scriplets; we don't want to depend on other RPMs

	find /var/cache/yum/ -name \*.rpm | xargs rpm -q -p | \
	  xargs /usr/bin/yum -y -C --nogpgcheck --installroot=${workdir} \
  	  --setopt=tsflags=noscripts reinstall

	# sync the private yum/rpm databases back out
	rsync -av --delete ${workdir}/var/lib/yum/ /var/lib/yum/
	rsync -av --delete ${workdir}/var/lib/rpm/ /var/lib/rpm/

Now, I see another transaction ID:

	[root@localhost ~]# yum history list
	Loaded plugins: fastestmirror
	ID     | Login user               | Date and time    | Action(s)      |
	Altered
	-------------------------------------------------------------------
     	3 | root <root>              | 2015-11-05 11:37 | Reinstall      |   11
	<
     	2 | root <root>              | 2015-11-05 10:36 | Install        |    2
	>
     	1 | System <unset>           | 2015-11-05 10:21 | Install        |  205
	history list

Looks like I'm full of win, right?

However, when I then try a rollback to tid 1, it does undo the
yum-utils+ rsync transaction (tid 2), but then decides it's going
to reinstall everything from tid 3, for some reason.

	[root@localhost ~]# yum  history rollback force 1
	...
	Transaction Summary
	==========================================================
	Remove        2 Package(s)
	Reinstall    11 Package(s)
	...

Obviously, I'm way off into uncharted/unsupported territory, but
if anyone has a more clue about what yum is doing here; I'd be
thrilled to hear from you...

-- 
Brian Reichert				<reichert@xxxxxxxxxxx>
BSD admin/developer at large	
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux