Red Hat Bugzilla – Bug 173400
inconsistent rpm numbering 6.8.2-62 -> 0.99.2-2
Last modified: 2007-11-30 17:11:17 EST
Description of problem:
Inconsistent rpm numbering of some xorg-xll rpms. The old version
was: 6.8.2-62 and the next version is: 0.99.2-2
Looks like a typo. These should probably be 6.99.2-2
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Not a bug (at least in my eyes), please have a look to the upstream file names
for example at http://xorg.freedesktop.org/X11R7.0-RC0/
It would be fine if these were new names, but these rpms replace rpms of the
same name, and so should take a higher number.
The alternative is to give them a new name, and any version numer you like to
start with, then use obsoletes to deprecate the old name.
These rpms are not even self-consistent with the rest of the X11R7 rpms which
have been numbered 6.99....
This is not a bug. The old packages of the same name, used to be subpackages
of the monolithic "xorg-x11" package, and so they took on the version and
release of the entire X.Org X11 release as a whole. These applications
previously did not have their own individual version numbers.
In the modular X world however, every single application, driver, library,
etc. is its own individual tarball, with its own individual version number,
on its own release cycle. These packages are now individually packaged in
their own individual src.rpm packages, and are not subpackages of a larger
twm is version 0.99.1 of upstream twm
xauth is version 0.99.2 of upstream xauth
These software packages are now individually maintained, and are not tied
to an X release. A new version of twm, xauth, xdm, etc. can be released
by the upstream maintainer of the given app at any time, not just when a
new Xorg X11 release comes out. As such, the new packages take on the
official version number of the software inside, which is the versions that
This is not a problem in any way, as the packages have had their rpm
Epoch bumped to 1, to ensure upgrades and dependencies continue to work
flawlessly as expected.
(In reply to comment #2)
> It would be fine if these were new names, but these rpms replace rpms of the
> same name, and so should take a higher number.
They do replace rpms of the same name, but they will not be taking higher
version numbers. They are now the version of the upstream package, and
it will stay that way.
> The alternative is to give them a new name, and any version numer you like to
> start with, then use obsoletes to deprecate the old name.
That was considered also, however it was decided to keep the same
names and bump the rpm epoch to ensure upgrades work instead. This
does not cause any problems.
> These rpms are not even self-consistent with the rest of the X11R7 rpms which
> have been numbered 6.99....
Some of the packages are of an individual application such as twm,
xdm, etc. and contain only that one app, or may contain that app,
plus utilities and/or data for that app. In these cases, I have chosen
to use the "primary" package version number for the rpm package. xfs
is a good example of this. It contains multiple tarballs including the
xfs tarball. The package version is the xfs tarball version, which is
the most important tarball in the package. The rpm version of these
type of aggregate packages, will follow this versioning style
consistently in the future.
There are other packages, which do not really have a "main tarball",
as they're just a collection of various utilities of a similar group,
into a single rpm package. Where the package name was not previously
used, I somewhat arbitrarily chose "0.99.<release candidate number>"
for the package, for lack of a better choice. The version number is
fairly arbitrary on these packages, because they are not grouped
together upstream. The versioning of the package is of the collection
as an aggregation, and is not tied to any one package in the
group, nor to the X11R7 release.
I will be reviewing the versioning of all the packages for FC5 test2,
and if I've missed bumping an Epoch and setting a version on any of
the ones that I had planned on doing that too, I'll fix it by then.
Setting status to "NOTABUG", as the versioning of the modular X
packages in Fedora devel is intentional, and non-problematic due
to proper use of rpm Epoch tags.