oVirt package names potentially collide with Fedora

[Mike Burns]

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 at redhat.com Red Hat Czech RHEV-M SLA / Brno,
> CZ
>
> _______________________________________________ Infra mailing list
> Infra at ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
>