[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
jhogarth reported a new issue against the project: `atomic-wg` that you are following:
``
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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/235