Backwards compatibility of the RPM format

[Avi Kivity]

On 02/10/2018 17.06, Panu Matilainen wrote:
> 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.


I already tested Fedora 28 -> RHEL 7. I'm concerned about Fedora 28+K -> 
RHEL 7, for increasing values of K.


I'm happy to tweak, as long as the tweaks are documented somewhere.


>>
>>   - 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.


Can you point me at the documentation for this? I'm not above 
trial-and-error tweaking if needed.


>
>>
>>   - 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.
>

We test the rpm right after building, and in the worst case we just 
update the flags and create a new rpm. As long as there commitment to 
make it work, rather than it working by accident, I'm happy to use this 
method. And it looks like there is.