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