#235 Container guidelines for versioning of packages in the container
Closed: Fixed 7 years ago Opened 7 years ago by jhogarth.

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.


Metadata Update from @dustymabe:
- Issue tagged with: containers

7 years ago

For me, version represents the container image, not the software inside -- it's really convenient to version them the same way, but it definitely shouldn't be a requirement.

For me, version represents the container image, not the software inside -- it's really convenient to version them the same way, but it definitely shouldn't be a requirement.

I had thought of the release as being the version of the container image. It does make sense to me that the version would correspond to the upstream "main program"'s version.

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.

Metadata Update from @jberkus:
- Issue tagged with: VFAD

7 years ago

@jberkus We can discuss this on the first half.

Metadata Update from @jberkus:
- Issue untagged with: VFAD
- Issue set to the milestone: 2017-03-10 VFAD

7 years ago

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

Metadata Update from @jberkus:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

7 years ago

Metadata Update from @jberkus:
- Issue assigned to maxamillion

7 years ago

FYI: issue to track the progress of "automatic versioning" is here https://pagure.io/atomic-wg/issue/249

Login to comment on this ticket.

Metadata