XFree86 @devel vs @updates
Mike A. Harris
mharris at redhat.com
Sat Feb 14 04:29:44 UTC 2004
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
More information about the devel
mailing list