6:16 a.m.
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.
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.
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.
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.
--
Martin Sivák
msivak(a)redhat.com
Red Hat Czech
RHEV-M SLA / Brno, CZ
9:10 a.m.
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(a)redhat.com Red Hat Czech RHEV-M SLA / Brno,
CZ
_______________________________________________ Infra mailing list
Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
3873
days inactive
3879
days old
1 comments
2 participants
participants (2)
-
Martin Sivak -
Mike Burns