Presently, the RPM package layout of elements is such that the later addition of
a signature can 'move' the payload start offset of a package, and prevent remote
'byte-range' retrieval deterministic knowledge of the 'end' of the header and
the 'start' of the body package.

This also would permit separate byte range retrieval of both header and body
components, and should permit a remote client to self-build a 'yum-arch' header
information base without central repository pre-processing. This is exciting,
because it makes EVERY simple FTP archive of RPMs susceptible to yum/up2date ish
access, even if not actively in maintenance.

Also, the 'stale' archive problem is lessened, because the client can always
re-query the latest information through a byte-range retrieval, and know that it
has accurate data.

So as we move to new repository models, with detached headers (a la yum), it is
useful to be able to then retrieve 'just' the body component.  

[08:27] <jbj> skvidal: better than explicit byte range is to pad signature
header so that metadata is always at constant offset. doable, somebody ask me
please.
[08:27] * jbj rats, fighting legacy again again again, 2 year wait sigh.

Please consider this a formal RFE that this occur, to permit more effecient RPM
management.  It should not particularly adversely affect the existing RPM
codebase, as alignment slack in the header structure should simply be ignored by
legacy rpm and librpm code out there.

-- Russ Herrold