Bug 103561 - RFE: package padding to permit precise payload and header break determination
Summary: RFE: package padding to permit precise payload and header break determination
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-02 13:43 UTC by R P Herrold
Modified: 2014-01-21 22:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-29 16:08:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description R P Herrold 2003-09-02 13:43:19 UTC
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
[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

Comment 1 Paul Nasrat 2005-11-29 16:08:21 UTC
yum is now using xml rpm metadata. Upstream rpm is considering new header
formats, so I'm closing this as RFE given the age and the upstream factors.

Note You need to log in before you can comment on or make changes to this bug.