- 1 What version of Red Hat Linux and Fedora Core is maintained by Fedora Legacy Project and for how long?
- 2 What is Fedora Legacy - Community Maintenance Project?
- 3 How trustworthy are Fedora Legacy resources?
- 4 What is the update policy for The Fedora Legacy Project?
- 5 What does the 1-2-3 and out policy mean?
- 6 Is the length of updates lifecyle above rigid?
- 7 What machine architectures are maintained?
- 8 Why are there non-i386 packages in the i386 directory?
- 9 How do I get notifications about new updates as they become available?
- 10 How fast are updates released?
- 11 How do I update packages?
- 12 Where can I get more info on Yum or Apt?
- 13 I don't already have yum or apt? Which should I use?
- 14 Why won't yum update my kernel?
What version of Red Hat Linux and Fedora Core is maintained by Fedora Legacy Project and for how long?
We are currently maintaining Red Hat Linux 7.3 and 9 as well as Fedora Core 3 and 4 as these have been transferred into maintenance mode from Fedora Core. We will provide updates for these releases for as long as there is community interest though we in general follow the 1-2-3 and out policy. This provides an effective supported lifetime (Fedora Core plus Fedora Legacy Support) of approximately 1.5 years or even more.
What is Fedora Legacy - Community Maintenance Project?
The Fedora Legacy Project is a community-supported open source project to extend the lifecycle of select 'maintenace mode' Red Hat Linux and Fedora Core distributions. Fedora Legacy is a formal project of the Fedora Project. Red Hat donates some services for it.
How trustworthy are Fedora Legacy resources?
Fedora Legacy is a community based project. As such, it is run by the community, and the people involved may change at any time without warning. To be sure the output of this type of system is correct, strict procedures must be followed, and all submissions must be "signed" so as to identify the creator.
Groups of maintainers will produce signed updates for their packages; these updates will undergo Quality Assurance (QA) testing as well as general user testing before being released. Only once we've received signed testing data verifying the update can it be released. Digital signatures at each step of the process help ensure the integrity of the process.
To be sure Fedora Legacy resources are trustworthy, the use of GPG keys is used when and where possible. For more information, please see the Security page about GPG validation before trusting any Fedora Legacy resources.
What is the update policy for The Fedora Legacy Project?
In general, we will provide security updates and critical bug fixes for select versions of Red Hat Linux and Fedora Core releases. No new features or packages will be introduced except where they are required for future management of our updates and agreed upon by a consensus. While updates are created primarily for security fixes, sometimes non-security bug fix updates may be allowed if consensus agrees that there is a serious enough need.
In most cases, fixes are back-ported to the current package version rather than upgrading the package to a newer version. This is done in order to limit the possible side-effects which can result from an upgrade. Packages are only upgraded to a newer version if consensus dictates that we should do so for some specific reason. Refer to Red Hat's backport policy for a detailed explanation of a similar guideline,
In order to publish security updates in a timely manner, security updates have a higher priority than any other updates. Within the class of security updates, network exposed vulnerabilities and services have the highest priority, while all other applications have a lower development priority. Extra packages have a lower priority than those in the base distribution.
For Red Hat Linux and Fedora Core releases under maintenance mode, we will continue to issue back-port security or critical fixes for as long as there is community interest and participation. We will in general follow the 1-2-3 and out policy.
What does the 1-2-3 and out policy mean?
Fedora Core releases will follow the so-called "1-2-3 and out" policy in co-operation with Red Hat and the Fedora Core project. This means that when the Fedora Core project group no longer supports a Fedora Core release, Fedora Legacy will pick it up and maintain it for two additional Fedora Core release cycles or even more based on community interest and participation. Based on the current schedule for Fedora Core releases, this should provide each release with approximately 1.5 years or more of total updates.
In short, Fedora Legacy will provide updates for any Fedora Core releases up to two versions back from the current release and more based on community interest and participation.
Is the length of updates lifecyle above rigid?
No. We may drop a release earlier if there is not sufficient community participation to continue maintaining it. Also, the above time periods should be considered to be a "at least this long" type of definition. If there is significant interest and community support in a release, and enough reason to do so, we may extend the life span of a release longer than the above defined periods.
What machine architectures are maintained?
Currently we support x86 (i386) and x86_64. PPC support is coming soon for Fedora Core 4 and above.
With Red Hat Linux, only x86 architectures will be supported.
With Fedora Core, we will attempt to provide support for all architectures for which Fedora Core has official support. However, our support will depend on the availability of those architectures and availability of community support for QA testing.
We always provide source RPM packages so that people using other architectures can rebuild them for use on their architecture. However, it should be noted if you do this that no QA testing may have been done on that architecture.
Why are there non-i386 packages in the i386 directory?
Like Fedora, we decided not to use the method of splitting sub-architecture packages up like Red Hat Linux did. We separate by base architecture, not sub-architecture. Examples of base architectures are i386, x86_64, sparc, etc. Examples of sub-architectures of i386 are i486, i586, i686, and athlon. RPM, yum, and apt are all capable of sorting them out and using the appropriate.
How do I get notifications about new updates as they become available?
We have created a mailing list called fedora-legacy-announce for posting information about newly published updates. Refer to our ["Communicate"] mailing list information at more information about subscribing to and using our mailing lists.
Additionally, you may set up a cron job to let apt or yum tell you when new packages become available, or even to install them automatically.
How fast are updates released?
Updates are released as soon as they pass QA. An update must pass QA for all supported versions before any of the versions are released. It is hard to say how quickly any given update will be released, as it depends on volunteers to do both the update development and the QA process. Hence, while we strive for timely updates, we cannot promise them. Release time depends heavily on community participation in the process.
In addition, there is a transition period during which Fedora Core releases are passed from The Fedora Project to The Fedora Legacy Project. This transition period may take some time, and during this time no updates can be released for the version being transitioned. We're continually striving to reduce the amount of time it takes to transition releases to Fedora Legacy.
How do I update packages?
We strongly suggest to install yum on your system. These are RPM-based package management systems who can help you in keeping your system up to date. Please follow the detailed instructions found on the Download page.
If you don't want to use yum, you can manually download and upgrade packages. You can find updates of existing packages in the updates tree (Fedora Legacy packages are marked with the word "legacy" in the RPM filename); additional Legacy packages which did not exist in the original distribution, such as apt and yum, can be found in the legacy-utils tree.
A list of currently available repository trees is available at http://download.fedoralegacy.org/. A list of mirror sites is also available.
Where can I get more info on Yum or Apt?
Refer to ["Legacy"] for additional information and usage examples.
I don't already have yum or apt? Which should I use?
If you don't already know anything about either of these tools, we suggest you to try yum first. yum has fewer options, less complexity, and is generally easier to learn than apt. Remember that both tools will get the job done, and you can always switch between tools, even later, if you want to try apt instead.
Why won't yum update my kernel?
The Fedora Legacy yum package in earlier releases of Fedora Core was configured by default such that it will not automatically update your kernel. This is similar to the default policy Red Hat used with up2date. If you want yum to automatically update your kernel, you need to change the configuration file (/etc/yum.conf) to remove the kernel update exclusion (the line which reads something like exclude=kernel*).
If you do use yum to automatically update your kernel, it will do a kernel install (preserving your previous kernels) and not a kernel upgrade (which would remove any previous kernel versions). That way if there is any problem with the new kernel you can boot back to one of the previous kernels until the problem is resolved. The newer release of Fedora use the updated kernel by default and we have choosen to follow the same policy.
Is Fedora Legacy a replacement for Red Hat Enterprise Linux (RHEL)?
No. Red Hat Enterprise Linux (RHEL) is a commercial open source distribution with a paid support subscription. It guarantees, for a price, a multi-year bug and security errata program, with full support from a professional Red Hat staff.
Fedora Legacy is a community project that is trying to provide free security updates (not bug fixes) to select legacy Red Hat Linux and Fedora Core Linux releases, for a short period of time. We do not charge or require registration, nor to we provide professional staff for support. Our only goal is to provide security errata (and the occasional critical bug fix, when required) to extend the life of a release for a short period of time.