Backwards compatibility of the RPM format

Panu Matilainen pmatilai at redhat.com
Tue Oct 2 14:06:25 UTC 2018


On 10/2/18 1:10 PM, Avi Kivity wrote:
> Hi, I'm considering moving from mock to rpmbuild, since simplifications 
> in my build process now allow it and rpmbuild is generally faster.
> 
> 
> A possible problem is incompatible changes in the format. If I build on 
> Fedora 28+, will the resulting RPM be installable on RHEL? The RPM is 
> self-contained and has no dependencies.

Depends on which RHEL, and all the other funny little details.

With a truly self-contained package without external dependencies it 
should be possible to build packages that can be installed on RHEL 3 
even, but it'll require some tweaking.
> 
>   - are the file formats compatible, and will they continue to be 
> compatible? I know that compression algorithms have changed, but perhaps 
> they were backported (or happened early enough to be included in RHEL)

The fundamental file format is basically unchanged, but like you note 
compression algorithms can differ. Impossible to say anything specific 
about comptibility without exact versions, but even if the older version 
doesn't support compressor X you can always just configure it to use 
good old gzip compression.

The rpm mechanism for dealing with incompatibilities is rpmlib() 
dependencies, which will prevent installation on a version that does not 
support the features a particular package requires. If such a feature 
gets backported, the same package will become installable.

> 
>   - are there flags I can specify to tell rpmbuild to restrict itself to 
> an older feature set?

Not quite like that, but once you know what you're targetting you can 
configure many things to compatible level. For some other features you 
might need to create spec conditionals.

> 
>   - is this a supported practice, or do you recommend against for 
> future-proofing?

Rpm goes to quite some lengths in the name of compatibility, BUT for 
best results, build on the target distro. That way any incompatibilities 
will be caught at build-time instead of install time, fewer hairy 
details to sort out and so on.

	- Panu -


More information about the Rpm-list mailing list