How do you know if the package was built with an older rpm vs. the new rpm? If
you can ascertain that, then you can surely have the latest rpm complain/warn
if it finds an rpm built with the latest rpm that doesn't have the tags, while
older rpm would be blissfully unaware, happy, and able to
Sorry but no, as we've already said several times in several places. Not for
this reason anyhow.
We want to be able to rely on this tag being there in packages built with a
modern rpm. And that is what the suggested change breaks. When you build it in
a container of the "target era", it's
What if a current RPM version complained about a package created w/o the tags?
It's already possible to generate them by simply using an older RPM version, so
I don't really see how "latest RPM always creates them" guarantees this feature
any more than latest RPM if patched to allow creation of
We are not planning to add such an option. While we have stricter requirement
for the backward compatibility of SRPMs than for normal packages they do not
include backward compatibility for all time. Closing.
--
Reply to this email directly or view it on GitHub:
Closed #2727 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2727#event-10766717419
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The problem with adding an option do disable it is precisely that it would then
be possible to disable it. As in, a feature you cannot rely on is a rather
broken feature.
Compressing the parsed spec would be quite reasonable, but we lack a general
mechanism to compress/uncompress header tag
For some packages, expanded specfile is so big, it causes srpm headers to
exceed 16 mb, which then can't be extracted by old rpms (pre 4.13) - they throw
an error, "headerRead failed: hdr data: BAD, no. of bytes(20966277) out of
range".
The code in question is in build/pack.c:
/* Include
