xorg-x11-6.9rc0+cvs rpm packages

[Mike A. Harris]

Sergio Monteiro Basto wrote:
> Hi, 
> Well, after some builds, I decide to show my humbled work to community 
> I had work on clean up xorg-x11.spec, hope that can be useful (for
> RedHat included).
> 
> http://sergiomb.no-ip.org/xorg/ have a little How to build rpm packages
> with latest sources from Xorg for Fedora Core 3.
> 
> any feed-back is wellcome

As an rpm packaging tip, I strongly recommend not putting any letters
after an upstream source's version number in the rpm package "Version"
field - even if the upstream source itself does this.  The reason is
that rpm can't tell wether the letters are "newer" or "older" than
the version without the numbers, and some software projects do it
one way, while others do it another way, so there is no way to
automatically be able to determine it without developer intervention.

As an example, one software project might version their packages
like this:

3.4	- Stable release
3.4a	- Stable release #2
3.4b	- Stable release #3
3.5	- Development release (odd minor)
3.5a	- Development release #2
3.5b	- Development release #3
3.6	- New stable release
3.6a	- New stable release #2

However another software project might name their versioning like
the following:

3.4	- Stable release
3.5	- Development release
3.5.1	- Development release #2
3.5.2	- Development release #3
3.6a	- Alpha/beta release for upcoming 3.6 release.
3.6b	- second alpha/beta
3.6	- Final 3.6 release.


Since both of these types of versioning schemes are in very common
practice in numerous projects, there is no way for rpm (or any other
piece of software) to know wether "3.6a" came first as a beta
release, then 3.6 came later as the stable release, or if 3.6 was
the first release and 3.6a was the second.

As such, it is highly recommended practice to omit the letters from
the version number, and put them as a subcomponent of the rpm
"Release" instead, so that upgrading from one release to the next
works properly always.  This avoids having to use an Epoch tag in
an rpm package, when the upstream versioning practices do not
increase in the order that rpm's rpmvercomp() compares them.

The method I've used to avoid these problems with X rpm packaging,
is to do:

Version: 6.8.99.8
Release: 0.cvs20050809.0

Subsequent rebuilds with changes, I increment the final .0 as
needed.  This pretty much guarantees every possible rpm upgrade
scenario will work, including cross-OS (with some additional
minor tweaks).

I would leave the "RC0" out of the rpm version for the Xorg
packages.  If you don't, when 6.9 does come out, and you update
to it, the "rc0" you used to have in the version field will
cause rpm to think the RC0 rpms are "newer" than the new 6.9
rpms you make are.  You'd then have to upgrade with --force
to get the final 6.9 installed.  Otherwise, you'd have to
add "Epoch: 1" to the package, which will forever have to
remain in your packages, and also has a side effect of
conflicting with the official distribution packaging.

Hope this helps..

TTYL