Well, I think I won't build it on COPR. That would defy the purpose of my efforts:-)
docker-rpm-builder itself is packaged through another project of mine,
- but I didn't even tell you on this
list, because for sure such project cannot be blessed by vendors, since it encourages
non-standard packaging practices.
docker-rpm-builder is created with the purpose of letting the "common developer"
(somebody who doesn't understand all the gory details of packaging) to build its
docker-rpm-builder was built because I didn't like things like copr (actually, I have
used copr only a bit, but we used a full Koji installation for years at my previous
employer), which I suppose uses mock under the hood, which in turn IMHO is quite a complex
piece of software with quite some quirky behaviours, and slowed me down quite a lot in
creating RPMs in the past. mock is quite low-level, importing and using rpm libraries on
the host, and setting up a complicate state for the chroot, while docker-rpm-builder is
plain-old-rpmbuild, just run into a container. First experiments of the tool actually
existed through Vagrant - that made them functional, but painfully slow.
I wanted to have something that I can fully understand. docker-rpm-builder is such a tool.
fpm-within-docker is its bastard son. I won't switch back to copr/mock/anything hosted
that I cannot try, use and understand on my own workstation :-)
Thanks for your interest! I suggest you pick somebody who doesn't know a lot about RPM
packaging and must learn, in order to really evaluate the tool. At my previous employer I
was once the "rpm master" - almost everybody delegated packaging tasks, or at
least relied on my help, to get the thing done. Since docker-rpm-builder inception people
started building packages completely by themselves, and have continued to do so happily
even without me. So I think it's a huge success, from my pratical perspective.