[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
dustymabe added a new comment to an issue you are following: `` FYI: issue to track the progress of "automatic versioning" is here https://pagure.io/atomic-wg/issue/249 `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/235 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
jberkus added a new comment to an issue you are following: `` Update from VFAD: The VERSION label and tag will be populated with a "0" until such time as it can be automatically populated based on the "primary" RPM in the container. The RELEASE will be incremented both by the maintainer on any manual change to the package, and by the autobuilder on autobuild. More details in Container Guidelines: https://fedoraproject.org/wiki/Container:Guidelines#VERSIONING `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/235 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
The status of the issue: `Container guidelines for versioning of packages in the container` of project: `atomic-wg` has been updated to: Closed as Fixed by jberkus. https://pagure.io/atomic-wg/issue/235 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
The issue: `Container guidelines for versioning of packages in the container` of project: `atomic-wg` has been assigned to `maxamillion` by jberkus. https://pagure.io/atomic-wg/issue/235 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
trishnag added a new comment to an issue you are following: `` @jberkus We can discuss this on the first half. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/235 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #235 `Container guidelines for versioning of packages in the container`
jhogarth added a new comment to an issue you are following: `` If that's the case we should make that clear on the guidelines. And I'm not sure what the point of a full NVRA is in that situation. What is the difference between `version` and `release` meant to mean? With RPMs this is obvious as version is directly linked to the upstream version and the release a fedora specific increment for changes in fedora based on that version. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/235 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[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
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
