Hi Martin Thanks for the feedback, and I'll try to answer your questions with both how we're tackling this now and how we want to approach it in the future. On 09/12/2013 09:16 AM, Martin Sivak wrote:

Hi,

I noticed that we use -N.fcXX as our release string for packages (ovirt-engine-3.3-1.fc19.noarch.rpm for example). The release number should be unique for a given version and distribution, but our packages are using the same naming as the official Fedora packages.

Why this can be an issue?

Imagine a situation when somebody (us or somebody from the community) packages an ovirt component for Fedora. Official Fedora packages use -N.fcXX in their N-V-R (name-version-release) string. At that time, both ovirt and Fedora rpms (ovirt-project-<version>-1.fc20.noarch.rpm) will have the same name and contain the same code. They won't be identical, but will at least probably behave the same way.

Then a Fedora release will approach and Fedora release engineers will do a Mass rebuild (https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild). They will bump the release number of the Fedora package by one (-2.fc20.noarch.rpm).

Now ovirt does a new upstream release (same code, but a dependency will change for example) and bump the release number by one. At that time, there will be two packages named ovirt-project-<version>-2.fc20.noarch.rpm with a different content.

Yes, this would be a problem, but we've taken steps to avoid this. We have rules in place with packages that are not built in Koji that they when they update, they update the version, not the release. So the existing package for oVirt would be ovirt-project-3.3.0-1.fc19.noarch.rpm The next one would be either of these: ovirt-project-3.3.1-1.fc19.noarch.rpm (for a planned bug fix release) ovirt-project-3.3.0.1-1.fc19.noarch.rpm (for an unplanned critical bug fix update) Thus, Fedora would have 3.3.0-2, but oVirt would provide either 3.3.1-1 or 3.3.0.1-1 avoiding the conflict you've mentioned. FWIW, this is not actually an issue anyway (explained below after the alternate solution)

Solution?

To make easier to debug these version clashes between upstream and downstream packages I propose changing the %{dist} tag our build system uses (globally) to "ovirt.fcXX". It will still indicate the proper Fedora version, but will make it obvious that the packages weren't built as official Fedora packages (in koji) but as "official" ovirt packages in Jenkins. And it won't require changing single line in any of our spec files.

This would be doable, but we don't really have a consistent build mechanism (a problem that we're attempting to handle).

Alternate solution?

The best solution with regards to dist versioning would be to make it mandatory to have all packages that need to export officially in Fedora and take the Fedora rpms from Koji. The same probably applies to other distributions we might support in the future.

Btw: We really should be building packages for Fedora on the proper Fedora (in mock) to avoid issues caused by library and compiler differences between our build system and Koji. If we are doing that than all is well, but I just wanted to be sure.

Yes, I completely agree that packages should be built in Koji for fcXX (and even the el6) builds. The reason that we don't do this today is that we can't. There are build dependencies that we haven't been able to get into Fedora for some of the components (gwt for ovirt-engine) and some things just are not Fedora acceptable (ovirt-node-iso, ovirt-release). We tried to put ovirt-engine in Fedora directly a while ago (3.0 timeframe), but ran into problems with gwt. We ended up with a stripped down, crippled version that still is in Fedora today. The time is probably ripe for another attempt to get gwt in and get oVirt in fedora as well. For ovirt-node-iso, this is basically an rpm containing a Fedora Remix LiveCD iso. It's something we could conceivable put into Fedora, but most people just take the bare iso and not the rpm and there is no good distribution mechanism through Fedora for the ISO. Packaging it and putting it in Fedora would make little sense. ovirt-release is simply an rpm with our required repositories. My understanding is that it would break packaging rules to include references to external non-fedora repos. We include things like Gluster repos (when new gluster is available but not yet in Fedora), virt-preview repos (new virtualization components that aren't in the current fedora), etc. We have some other non-Fedora components (otopi, ovirt-host-deploy, api, sdk, etc) that would probably fit in Fedora perfectly fine, but without the ovirt-engine packages, there is little value in the effort. Packaging them would be part of the overall ovirt-engine packaging effort. Other components do actually exist in Fedora today. vdsm is built and packaged through Koji and those builds are basically copied from Koji into the ovirt.org repositories. ovirt-node is also included in Fedora today. We do something very similar to what is outlined above, where we only bump the version string on ovirt.org so that Koji rebuilds won't conflict.

I am really curious about how we deal with this or if we actually care, but since I am a Fedora packager myself I just thought I would ask to make sure I use the proper release procedures for my components.

There does need to be some effort made to put the other oVirt components into Fedora so that it's easier for people to get oVirt up and running. I think overall, you have valid concerns, but I don't see the missing oVirt packages going into Fedora/Koji until oVirt Engine can go in and there are real blockers there. I hope I've answered you questions. Mike

-- Martin Sivák msivak@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ

_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra