Some quick questions about RPMs: 1. What is the 'correct' method of arranging a set of update RPMs for a given package in chronological order? I'm currently using the file timestamp, but can I rely on mirror servers to preserve timestamps? At first I thought sorting by file name would work until I encountered kernel-2.6.9 and kernel-2.6.10 :) I see there is a build date field in the RPM header. Is that guaranteed to be in the correct order? 2. I need a quick and dirty way to get to calculate the payload offset within an RPM. I'm developing in Java so I can't use the RPM development libraries. I'm currently using the following code (it's in Java -- but I think it's obvious what's going on). At the end 'loc' holds the payload offset. It works for all RPMs in the FC3 distribution, *but* I had to fix the size of the signature structSize to 216 (a few RPMs reported 212 ?!). Obviously, despite working, I'm doing sometime wrong. // din is a InputStream for the RPM file. // din.skip(n) skips forward n bytes. // din.read() reads a byte from the stream // din.readInt() reads a 32 bit int (4 bytes) from the stream // skip lead din.skip(96); int loc = 96; if (!((din.read() == 0x8e) && (din.read() == 0xad) && (din.read() == 0xe8) && (din.read() == 0x01))) { System.err.println("start of signature magic not found"); return -1; } din.skip(4); int nIndexEntries = din.readInt(); int structSize = din.readInt(); // TODO: why this? <-- here is my problem: some rpms reported // 212, but if I used this value it failed. If I fix structSize to 216 all // the RPMs in the FC3 distribution work ! if (structSize==212) { structSize=216; } din.skip(nIndexEntries * 16 + structSize); loc += 16 + nIndexEntries * 16 + structSize; if (!((din.read() == 0x8e) && (din.read() == 0xad) && (din.read() == 0xe8) && (din.read() == 0x01))) { System.err.println("start of header magic not found"); return -1; } din.skip(4); nIndexEntries = din.readInt(); structSize = din.readInt(); din.skip(nIndexEntries * 16 + structSize); loc += 16 + nIndexEntries * 16 + structSize; Thanks, Joe.