In the 3/10/2017 VFAD, we decided that VERSION would be 0 pending updating FLIBS to support automatically pulling the version from the "primary RPM" in the container.
However, we are not currently collecting information from maintainers about which RPM is the primary one.
Should we have a label or structured comment, required, which contains this information?
Ref #235
@maxamillion @dustymabe
Metadata Update from @jberkus: - Issue tagged with: meeting
Metadata Update from @jberkus: - Issue tagged with: containers
it could be derived from the name of the container (i.e. the container should be named what the primary rpm name is), but I can see cases where we might want to override this. I'm +1 to being explicit and requiring some sort of identifying information, but maybe only if it is different than the name of the conatiner?
I think the number of cases where the name of the container is a truncated, or extended, name of the package is going to be fairly large.
This correlates directly to https://pagure.io/atomic-wg/issue/249 and my plan there is to effectively have a macro that can both identify that someone would like the VERSION autopopulated and also which RPM's version it should remain synchronized with. This is something I need to sort out in the OSBS and koji-containerbuild code bases in order to find out what method(s) are realistici to implement. From there I plan to write up a proposal and send to the mailing list as well as review in meeting.
It also needs to take into account that sometimes the field will be "N/A" for containers which don't correlate well to a package version number.
summary: we don't know what we want to use as identifying information right now so we can't draft guidelines just yet. Waiting on the outcome of investigation in #249 for that.
Thinking through the example of my kubernetes images:
kubernetes-apiserver, -scheduler, and -controller-manager each are based on kubernetes-master, for which the primary package is kubernetes-master -- basing it on the name would work for the master pkg, but not for the children, unless we're going to look at the parent image name and expect that to give us the primary rpm, which in this case, it would.
I guess in the auto-sensing scenario, we could ask the maintainer to put the primary package first in the list of packages that are dnf installed. There could still be complications w/ child images, though...
Anything which doesn't involve a field populated by the maintainer is going to fail.
No updates at this time, waiting on infra availability.
Metadata Update from @dustymabe: - Issue untagged with: meeting - Issue marked as blocking: #249 - Issue tagged with: blocked
Log in to comment on this ticket.