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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
