
Show HN: Fast native RPM building from any distro, for any distro, via Docker - alanfranzoni
https://github.com/alanfranz/docker-rpm-builder
======
rwmj
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.

Here was one of my favorites, which took weeks to diagnose:
[https://lists.nongnu.org/archive/html/qemu-
devel/2010-02/msg...](https://lists.nongnu.org/archive/html/qemu-
devel/2010-02/msg00823.html)

~~~
alanfranzoni
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!

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

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

~~~
peterwwillis
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

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

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

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

~~~
alanfranzoni
You could use fpm.

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.

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

