rpm-4.0.2 is released as an errata for all Red Hat platforms, and we
build packages against the latest released errata.

FWIW, rpm-4.0 has survived two Red Hat distro's already, it's
not exactly an "untested random variable". YMMV.

which two?

RH7.0 shipped with it, but RH7.1 was released AFTER rpm4 started being shoved down the update throat.  plus, rpm3 has had a lot of time out in the 
field.  rpm4 won't get that for a few years.  how big were the changes in rpm4?  the errate update wasn't exactly verbose on that...

Also, on the changeover, is rpm4 actually going to be documented? that is one of the things that greatly hurt on thr rpm3 change, rpm2 had great docs, 
ncluding Maximum RPM, rpm3 still doesn't have that level of docs.

Where have you been for the last several years? :-)

You might take a gander at www.rpm.org, as the rpmlib API is fairly
well documented using doxygen, something "Maximum RPM" never
did well ...

Okay, so I decided to take the plunge and so with the rpm's requiring rpmv4.  One REALLY big problem.  is there an instimage compatible with both 
rpmv4 and RH6.2?  Unless there is then I can't use the security updates that require rpmv4.

and in case you are wondering I tried using the RH6.2 one, and it doesn't work.

BTW, it shouldn't have been a security errata for rpm, the errata text
was released, but there's no way to undo what was originally done.

rpm-3.0.7 (unreleased, but on the rpm-3_0_5 branch in CVS) is the easiest
pathway for a 6.2 compatible installer. That version will install rpmv4
packaging
and do everything you need. Otherwise, you will have to backport changes
from the Red Hat 7.0 anaconda to use rpmdb iterators, a bit of a pain.

The only problem I'm awars of is a bit of  name space pollution with the
function

int cpioFileMapCmp(const void * a, const void * b)
{
    const char * afn = ((const struct cpioFileMapping *)a)->archivePath;
    const char * bfn = ((const struct cpioFileMapping *)b)->archivePath;

    /* Match payloads with ./ prefixes as well. */
    if (afn[0] == '.' && afn[1] == '/')        afn += 2;
    if (bfn[0] == '.' && bfn[1] == '/')        bfn += 2;

    return strcmp(afn, bfn);
}

Make sure that the function of the same name in the installer
is exactly the same. Bonus points if you also rename the
function within the installer.

Are there docs anywhere on how to toss new rpm binaries into the installer? (or can you give me a quick summary?)

I have been meaning to pick apart the internals of how the installer works, but haven't had time yet beyond diving into lots of kickstart usage...

did a quick peak and it looks like anaconca might just use under instimage:
/usr/bin/rpm and
/usr/lib/rpm 
(and other misc stuff)

so, am I correct in thinking I can just do a source build of rpm, and then copy the results in?

just asking because some of the installer stuff (like mount) is built in.

thanks

If you have the stomach for it, porting the 7.0 anaconda back to 6.2 is
a great learning mechanism. No (or very little) doco, but I suspect the
source is pretty informative.

Meanwhile, the 7.x anaconda interfaces to rpm *only* through python
bindings AFAIK. The killer is in other details, such as wide chars, mount
labels, kernel driver quirks and such that need some thought.

rpmlib-4.0.2 is *easy* compared to some of the other 6.2 -> 7.0 changes

Can't see any further problem here.

Well, the bad news the solution mentioned above didn't work out.

don't worry there is good news.

The good news is that RedHat support responded with a solution to Service request #180058 that did work well for me.

The basic idea is instead of merging the updates into the base RPMS set, leave the stock RPMS set unchanged, and do the updates as a part of the 
kickstart post section.  What this does is you don't have to get the install program up to rpm v4, you just upgrade the machine in %post to rpmv4 and then 
install the updates.

Which for others that have this problem, a quick look at what I did:

I through everything under a /intall/tl63 (tl63 meaning TrueLink and is RH 6.2 with changes)
sub-dirs:
RedHat - the normal RH6.2 image (including the RPMS sub-dir)
updates/rpm4 - the rpm v4 rpm and the db3 rpm (basically what is need to first update to rpm v4)
updates/i386 - the updates form RH minus the rpm4 ones and the kernel rpm's
updates/kernel - contains kernel updates seperately (so that same tree can support installs to i586's and i686's)
extras - some extra RPMS we have grabbed/built in house -- openssh, apache with mod_ssl support, sudo, etc.

snippets from the kickstart script:
------------------------
%post
# mount install tree again -- will allow us to grab sub scripts and patches, etc
mount <install IP>:/install /mnt

# update to rpm4
rpm -ivh /mnt/tl63/updates/rpm4/db3-3*.rpm
rpm -Fvh /mnt/tl63/updates/rpm4/rpm-4*.rpm

# grab updates to current packages
rpm -Fvh /mnt/tl63/updates/i386/*.rpm

# grab updated kernel for this arch
rpm -Fvh /mnt/tl63/updates/kernel/*.rpm
rpm -Fvh /mnt/tl63/updates/kernel/i686/*.rpm

# fix kernel lilo setup
perl -pi -e 's/14-5\.0/19-6.2.7/' /etc/lilo.conf
/sbin/lilo

<...>

# ALL DONE, umount
umount /mnt
------------------------
Which as a final note, I just wanted to express my thanks to everyone at RedHat for the great support I have gotten on this and other issues.  Compared 
to the lack of support we get from other vendors the level of support from RedHat is quite refreshing.

FYI, we found an issue with rpm v4 today.  the relocatable package we are building internally don't work under rpm v4.  we haven't looked into why yet.  We did the 
quick workaround of using the static rpm v3 binary for our installs or the relocatable package (we use a seperate rpmdb for them already so wasn't a big problem).  
basically looks like a '/' is getting clipped out of the path (our rpm's have a prefix of /db  and when we tell it to install to foo/db it makes it foodb)

Relocations are broken in rpm-4.0.2, fixed in rpm-4.0.3. FWIW, you should
be trying to use rpm-4.0.3-0.92 or later, bits are cooked, release is imminent.

thanks for the heads up.  we will be anxiously awaiting 4.0.3 :)