Generating a source rpm is not required to build a binary rpm, so I don't get the point of this tool. All you need to build a binary RPM is a .spec file. The spec file can then determine how to build and package it, like using sources already on disk, downloading sources, using a list of pre-compiled or noarch files, etc.
Building RPMS is typically a platform-specific thing, because most distributions bastardize their systems to be incompatible with others' RPMs. RPMs provided by vendors and 3rd parties typically shove everything into /opt and depend on very little to work around this. If you want your package to be portable you should probably do the same.
RPM is a packaging format, not a packaging standard. Fedora has a massive set of guidelines. OpenSUSE has a massive and different set of guidelines, because it's a different distro with different goals. Mandriva, another set. And so on. The fact they all happen to use RPM is pretty much irrelevant.
This is true, but they're also all Linux distributions providing exactly the same software, and all duplicating hundreds of hours of effort per package by doing exactly the same thing with tiny incompatible differences. It doesn't have to be that way. For example, they could provide shims for the incompatibilities in each others' standards so the packages edit: spec files could be reused without breaking on other systems. But instead they work in silos. Sigh
This is a problem (if you consider it a problem) of all Linux distros. It's just that people look at the foo.rpm file and think it should be installable anywhere, but no one would look at a foo.deb file and think they could install it on Arch.
If Debian packages only required a single text file to build everything, they could! It would be simple for the distros to combine their efforts on a single .spec file. Back in the day I used to make RPM .specs that would build the package successfully on Solaris, Linux, Windows, etc and then had tools to convert the RPM into a native package format for easier maintenance. Writing an rpm2dstream script took just a couple hours.
THe .src.rpm is not required if you use rpmbuild (which is what docker-rpm-builder does inside the container) but AFAIK you need to build a .src.rpm if you want to use mock.
Building RPMs is a platform specific thing indeed, and the /opt way is a very common way to go (docker-rpm-builder itself is installed in /opt in my prebuilt packages), but you still want to compile in an enviroment as close as the target to be sure your software works.
Everything old is new again. 'mock' and various SUSE tools have done this for a decade or more.
I'm waiting for the fun to start when they realize that using a different kernel from the one the distro is designed for causes all sorts of crazy-hard-to-find bugs. Been there with mock, several times.
Been there with FPM, too. This is probably handy for platform-independent applications like Java, maybe Python, but with anything native you'll have to compile things on the lowest-common-denominator of glibc out of all the systems you're targeting, and that means for many applications you'll be missing features that you could take advantage on newer systems.
You are right, the kernel is still a dependency. But I canno solve all problems - at least my proposal is not worse than mock, and it solves some major nuisances with it, especially the difficulty of debugging build issues.
I'll add the note about kernel importance in the docs, though. Thanks!
Does anyone have a use for a tool to assemble an RPM without using a .spec file and the rpmbuild process? I.e., something that works on a combination of pre-built binaries (in a .tar file) along with a .manifest file?
I was putting something together like that a while ago for packaging up software for internal use, that we get from outside vendors. I can dig it up and throw it on Github if anyone is interested.
I use FPM (https://github.com/jordansissel/fpm) for that and it works wonderfully. You can convert a tarball to RPM/deb pretty seamlessly most of the time.
But the point is: can you pack every single dependency in your project? Usually you'll need something from the outside distro (libc usually). Then if you're building on a different host than your target, you may experience issues or different runtime behaviour.
It depends what you're packaging. C/C++ code linked against dynamic libraries? Yes, you're going to struggle to package reliably without using the native tools. Java code packaged as a bundle of jars, with no dependency except a JVM? Go code compiled statically, with no dependency except libc? Simple portable packaging should do the job.
16 comments
[ 4.2 ms ] story [ 62.4 ms ] threadBuilding RPMS is typically a platform-specific thing, because most distributions bastardize their systems to be incompatible with others' RPMs. RPMs provided by vendors and 3rd parties typically shove everything into /opt and depend on very little to work around this. If you want your package to be portable you should probably do the same.
Building RPMs is a platform specific thing indeed, and the /opt way is a very common way to go (docker-rpm-builder itself is installed in /opt in my prebuilt packages), but you still want to compile in an enviroment as close as the target to be sure your software works.
I'm waiting for the fun to start when they realize that using a different kernel from the one the distro is designed for causes all sorts of crazy-hard-to-find bugs. Been there with mock, several times.
Here was one of my favorites, which took weeks to diagnose: https://lists.nongnu.org/archive/html/qemu-devel/2010-02/msg...
I'll add the note about kernel importance in the docs, though. Thanks!
I was putting something together like that a while ago for packaging up software for internal use, that we get from outside vendors. I can dig it up and throw it on Github if anyone is interested.
I was thinking about a docker-fpm-builder myself by the way, so maybe we'll meet again :-)
- Make a spec with / (actually the build root) in %files section
- Run the build
- List the resulting package contents (which is whatever was put into the build root)
- Manually remove any common dirs
- Update the %files section and rebuild
But the point is: can you pack every single dependency in your project? Usually you'll need something from the outside distro (libc usually). Then if you're building on a different host than your target, you may experience issues or different runtime behaviour.