Generally, I'm OK with this, but let's wait for another opinion.

One thing I don't really like, is that very busy RUN command... wondering if using S2I wouldn't make things nicer... Although that should be also hacked to make sure, that dependencies come from RPMs and not requirements.txt.

(The Jenkins results seem to be for the wrong PR.)

I don't understand the background on this, but for whatever my opinion is still worth I would be -1 on this...

The huge RUN command looks pretty nasty. It is basically just repeating all the work that is already in the spec file, but in a less organised way. I don't see how bypassing the RPM gains any benefit.

@csomh I don't know S2I for this kind of use before...Would like to have a look.
@dcallagh The intention of this change is to make it possible to build container images via OpenShift's Builds. The current Dockerfile uses external RPMs on disk, which makes it harder to leverage the Build Strategies supported by OpenShift.

If we have to install from RPMs, there are only 2 options:

1. Building RPMs in dockerfile, install, then remove them and their build dependencies. This will make the Dockerfile more complex.
2. Using an external process to provide built RPMs.

Building RPMs in dockerfile, install, then remove them and their build dependencies. This will make the Dockerfile more complex.

I think this could be done with multi-stage Docker build (build RPM in the first stage and pass it to the next one).

@lholecek Thanks for your information.
Multi-stage Docker build requires Docker 17.05+. I will check if UpShift supports that.

@lholecek Well, bad news: The docker used by UpShift doesn't support multi-stage builds.

Another approach could be a trick used in Content Delivery CI: Build RPMs and a temporary YUM repo in the dev pipeline, then expose the repo as an Archive on Jenkins so that docker build is able to access that repo via HTTP. The downside is that the BuildConfig cannot be used individually. You have to run the dev pipeline first to get a valid repo, then start a docker build with passing the URL of the repo thorough a build parameter.

@rayson: would you be against marking as WIP or closing this until we come up with a better solution to get building RPMs into the process?

I will mark this PR as WIP.