XFree86 @devel vs @updates

[Mike A. Harris]

On Fri, 13 Feb 2004, Luciano Miguel Ferreira Rocha wrote:

>Date: Fri, 13 Feb 2004 22:07:46 +0000
>From: Luciano Miguel Ferreira Rocha <strange at nsk.no-ip.org>
>To: fedora-devel-list at redhat.com
>Content-Type: text/plain; charset=us-ascii
>List-Id: Development discussions related to Fedora Core
>    <fedora-devel-list.redhat.com>
>Subject: XFree86 @devel vs @updates
>
>
>Hello,
>
>I've been tracking fedora-devel for some weeks, but I also track FC1 updates &
>updates-testing.
>
>Today I updated my fedora-devel mirror and I see XFree86-4.3.0-45.0.2
>packages, but on FC1 updates-testing there are XFree86-4.3.0-50, that rpm
>and yum consider above the development version.
>
>So which should I use? Which one is the more up to date?

The XFree86 4.3.0 src.rpm is 100% shared between:

- Red Hat Linux 9 
- Red Hat Enterprise Linux 3 
- Fedora Core 1 
- Fedora development 
- Red Hat Linux 8.0 (It can be built 'unofficially' for RHL 8.0
  with the addition of some RHL 9 packages to the system.)

Packages built for RHL 8.0, I set the release tag to "1.80.n", 
packages for RHL 9, the release tag is set to "1.90.n", and 
packages for RHEL, the release tag is set to "n.EL", where Fedora 
Core 1 erratum, as well as Fedora development, I set the release 
simply to "n".

So, for release '55', which is the absolute latest one, which was 
just released as erratum across the board, the release number for 
each product is:

RHL8.0	- 1.80.55 (my personal unofficial builds [1])
RHL9	- 2.90.55
RHEL3	- 55.EL
FC1	- 55
devel	- whatever random number of the day/week/month I decide 
          to use in order to confuse people.  It might even go 
          backwards, or use irrational numbers.


The value of 'n' is what determines which is the 'latest' for the 
given release.  The binary packages for each of the above OS 
releases are not all build 100% identically.  Inside the spec 
file, there are 5 rpm macros to determine what OS release the 
package should be configured to build for.  Depending on which of 
the 5 macros is set to "1", the build is reconfigured to build 
especially for that particular OS release.

The macros are:

%if ! %{build_autodetect_mode}
# Set *one* of the following build targets to 1 as appropriate
# Fedora Core development builds a.k.a. "rawhide"
%define build_rawhide           0
# Fedora Core 1
%define build_yarrow            1
# Red Hat Enterprise Linux version 3 (AS/WS/ES/PW)
%define build_taroon            0
# Red Hat Linux 9 (Shrike)
%define build_shrike            0
# Red Hat Linux 8.0 (Psyche)
%define build_psyche            0


>From the above, my current spec file is configured to build 
Fedora Core 1 (Yarrow) packages.

The next question which might be on people's minds is "What are
the differences between each of the above build targets Mike?"

Each OS release, new enhancements are made, some of which are 
experimental and need some time in rawhide testing, etc. before I 
can deem them worthy of being included in future erratum for 
older OS releases.  I wrap those changes in %if %{build_rawhide} 
checks in the spec file.  Over time, I may consider such a change 
stable enough to be considered ok for some or all of the other 
releases, and will change the conditionalizaton appropriately.

Other changes and improvements made, sometimes require features 
only present in a particular OS release or releases, and so I 
have to conditionalize the inclusion of those features to just 
the releases it will work on.  An example of this is our libGL 
optimization patch:

# Only apply this to Cambridge and Taroon builds
%define with_libGL_opt_patch    %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' -o '%{build_taroon}' -eq '1' ] && echo 1 || echo 0)

The above support wont work on older OS releases due to requiring 
new gcc and/or glibc and/or kernel support for example.


# Only apply to Cambridge until well tested, then apply to Taroon also.
%define with_libGL_exec_shield_fixes    %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' ] && echo 1 || echo 0)

This is an example of testing out exec-shield on Fedora Core
guinea pigs.  ;o)  The intent here being to test this
functionality well before applying the patches to other OS
releases.  The recent XFree86 security exploits which we just
released erratum for, were just tested with exec-shield enabled
and the X server was found not vulnerable to the exploit while
exec-shield was enabled.  So those running Fedora Core 1 or 
rawhide, who have exec-shield enabled, don't need to bother 
updating to fix the security issue that was just released.  I'll 
probably enable the above check on other OS releases once 
confirming we have exec-shield support on them.  ;o)

Anyhow...  It's Friday and I was a bit bored.  Having read 
through the subject lines of fedora-devel-list I found myself 
craving some actual development related content, kindof like a 
chocolate bar, and so I figured I'd post the above tidbits in 
case someone found them useful/informative, etc.

Perhaps I can even sucker some people into testing rawhide 
XFree86 out on previous OS releases now, and get even more test 
coverage.  ;o)

Anyhow, hope this is useful to someone... time to go read now..

TTYL

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat