Re: Reproducible builds; was: Re: RPM's that fail in %post...

[Jeff Johnson <jbj redhat com>]

On Thu, Jan 16, 2003 at 11:11:47AM -0500, R P Herrold wrote:
> 
> 2)  Is there a cheatsheat or set of common forms used with 
> trpm which we might see?
> 

First, trpm is an absolutely grotty script.

The problem that trpm solves for me is

	Select a subset of packages that have dependency closure
	without looking at dependencies.

This is very useful if, say, your distro is changing hour by hour,
platform by platform, upgrade by upgrade, rpm version by version, etc.

Basically all that trpm does is use globs to generate a bunch
of manifests that are likely to be closed wrto dependencies.

All the rest of trpm is window dressing for the rpm CLI. Hack to taste.

The attached message describes trpm usage about as well as anything
else. Note that the message was originally a request for --rollback
testing, but trpm used to install into a chroot is by no means
specific to --rollback.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC

All --

A little help testing "transaction rollbacks" in rpm-4.0.4-0.29, please,
while y'all are waiting for the anaconda to be cooked.

In a nut shell, transaction rollbacks are gonna be used by RHN
to provide an UNDO button somewhen soon. During an upgrade, --repackge puts
the old bits back into a package in the /var/spool/up2date directory
with a remove transaction id. Newly installed packages are marked with
an identical install transaction id. Finally, --rollback <timestamp>
replays transactions backwards, removing newly installed packages,
and re-installing the old packages, until the timestamp goal is reached.

Kinda simple and cute, huh? Esrever ni adnocana is anaconda in reverse.

Well, considering that
	rpm -Fvh --rollback "20 years ago"
is a *great* way to scrub your disk, we need some help testing,
as there's a zillion packages out there, and transaction rollbacks
are gonna be a bear to test and stabilize. This is a whole new
dimension to package management, and no one -- especially me -- has
a clue.

BTW, the clean disk problem has been addressed by terminating rollbacks
as soon as there are no more removed packages to be re-installed. There
are most certainly other problems, *lots* of them, *expect* --rollback
to break.

I've put a toy test script into /usr/lib/rpm/trpm in rpm-4.0.4-0.29.
I use this script daily for testing rpm install/upgrade into a chroot.
Yes, the script is grotty, WORKSFORME, but feel free to be creative.

Since it's a chroot, you can find a lot of problems w/o a great deal of
effort. I suggest using trpm to test 8.0 in a chroot as well. For example,
once you're set up properly, the following commands will get you an 8.0
chroot with enough packages to attempt a compilation:
	rm -rf 8.0
	./t 8.0 build --initdb -Uvh
	./t 8.0 chroot
In fact a great deal of package testing can be done within a chroot.

In order to use the trpm script, you need to do (hank is our QA
repository of distros past, mount CDROM's if you don't have access to
hank)
	mkdir -p /mnt/dist
	mount hank.test.redhat.com:/mnt/dist /mnt/dist
	for i in 5.2 6.0 6.1 6.2 7.0 7.1 7.2
	do
	    mkdir /$i
	    ln -sf ../mnt/dist/$i/i386/RedHat/RPMS/ /$i/i386
	done
to follow my convention(s). Or hack on trpm to roll your own convention,
'tain't hard.

Basically, /{7.2,7.1,...}/i386 should point to a pile of rpm's from the
corresponding distro RedHat/RPMS directory.

Then, to use trpm for testing --rollback (renamed to t below to accomodate my
fumble fingers), do

	mkdir -p /somewhere		# Make a playpen, you'll need disk space
	cd /somewhere			#

	cp /usr/lib/rpm/trpm t		# local copy for hacking

	./t 7.1 clean			# scrub
	./t 7.1 config manifest		# generate manifests (only needed once)
	./t 7.2 clean			# scrub
	./t 7.2 config manifest		# generate manifests (only needed once)

	ls -al .			# Hmmm, wassup?

	sudo rm -rf ./7.[012]		# wipe out the chroot's

	./t 7.1 $type --initdb -Uvh	# install 7.1 "min0" set

	mv ./7.1 ./7.2			# Prepare for 7.2 upgrade
	sudo rm -f ./7.2/var/lib/rpm/__db*	# XXX just in case

	sudo rm -f /var/spool/up2date/*.rpm	# XXX just in case
	./t 7.2 $type -Fvh --nodeps --repackage # 7.1 -> 7.2 upgrade

	sudo /bin/rpm -Fvv --nomd5 --root `pwd`/7.2 --rollback "1 hour ago"

Candidate install sets in increasing size currently in trpm are
	min0
	min1
	min2
	base
	devel
	build
	all
I use min0, min1, and build mostly. Feel free to augment the install
set globs if you wish. The sets above are known to work hen applied
5.2, 6.0, 6.1, 6.2, 7.0, 7.1, and 7.2 packages (more or less). I haven't
looked at 8.0 yet.

Dink a bit, and you'll figger it out.

Bugs in bugzilla, please, and attach at least the sequence of trpm
commands you ran so that I have a prayer of reproducing the problem.

Thanks for any/all help.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC