[Rpm-maint] [rpm-software-management/rpm] Retrofitting a format version on *.rpm packaging. (#172)

Jeff Johnson notifications at github.com
Tue Mar 7 16:40:05 UTC 2017


When originally written, the rpmlead contained information used to identify a *.rpm.

Twenty years later, most of the rpmlead information is de facto and ad hoc and historical.

Progress using other information, like rpmlib(...) tracking dependencies, has managed to associate
new "features" (actually "incompatibilities") with an installer that can handle the incompatibilities.
There are also magic numbers associated with each of the 4 components in a *.rpm package
(I assume that the new rpmarchive payload has an associated magic, but likely doesn't change format version).

(aside)
In fact, a tracking dependency would have avoided the last version 3->4 format version change
that caused LSB to dictate that all *.rpm packages MUST be version 3. *shrug*

Tracking dependencies implicitly assume that a Header (with magic) can be loaded, and
do not provide a mechanism by which signature/metadata headers can be changed to, say,
add a new data type to a Header, which would prevent a header being loaded, which prevents
a tracking dependency from being checked.

Fundamental sorts of signature/metadata changes might need format versioning (and additional
magic as well as tracking dependencies etc) to be handled correctly, unlike changes to a payload
format or payload checksum or adding RichDependencies (to name a few incompatibilities that
have been finessed through other means).

I can certainly devise a means to add a new data type to a Header, or replace a Header with a
different container structure (*.deb or *.xar sections in files in a wrapper archive), or even by
deliberately changing the rpmlead version++, or even by adding a different *.rpm suffix naming.

But the core problem remains:
    There is nothing but de facto and ad hoc techniques available to change *.rpm format.

I think its time to talk about an orderly way to change RPM format rather than waiting for
error reports to arrive.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/172
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170307/fdda5e17/attachment.html>


More information about the Rpm-maint mailing list