It's packaged for both Centos/RHEL7 and Fedora 23. The repos are listed in the readme. Do you mean "making it available on official EPEL and Fedora repos" ? I think I won't do that; usually such projects have certain requirements on packaging guidelines and/or upgrades and/or maintenance which go far beyond what I'm willing to invest - beyond the fact that I'd probably need to support the distro provided (or EPEL provided) docker version, multiplying the dependency paths which I should support. BTW if you find the tool useful and somebody wants to step up for such packaging/maintenance task, I'll be happy to accept upstream patches that let the compatibility exist, even though this would mean supporting legacy docker or python versions.

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, https://github.com/alanfranz/fpm-within-docker - 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 RPMs. 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. bye, Alan