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.

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(a)nsk.no-ip.org&gt; >To: fedora-devel-list(a)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