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
_______________________________________________
cloud mailing list -- [email protected]
To unsubscribe send an email to [email protected]
