Since the container build process uses stable repos it's tricky to time a container update alongside an update of key components.

It also leads to the question to the guidelines of "what does 'ENV NAME=myawesomecontainer VERSION=0.1 RELEASE=1 ARCH=x86_64' actually mean?"

In the case of the owncloud container review one would think it refers to owncloud itself (presently at 9.1.4) but the container also has httpd and php which may be susceptible to security issues and knowing the version within may be important.

There's also an issue of tying the version in the ENV to the actual package in place.

We should have something in the guidelines to ensure this. The RUN dnf -y install owncloud (in this instance) should probably have dnf -y install owncloud-${VERSION}-${RELEASE} in order to prevent race conditions, although this would have an effect on the proposed fortnightly build process with the timing between an RPM maintainer updating the package and the container maintainer presenting a container update.

We either need a way to attempt to automate this, accept failures and rebuilds or some other thing I haven't thought of.

In addition we should allow building the container from at least the testing repos, if not the koji buildroot or similar setup, to prevent a significant lag between an update in fedora and being able to provide that update in a container based service.

The worst case would be a package in updates-testing for a full week and a poorly timed move to stable with the next container build, as proposed elsewhere, two weeks away for a full three weeks for a potential vulnerability or major bug.