Personal tools
     DOCUMENTATION

rPath Linux:rPath Linux 2

From rPath Wiki

Jump to: navigation, search

Contents

rPath Linux 2

rPath Linux 2 is the second major release of rPath Linux.

Appliance Focus

rPath Linux 2 is focused on making customization, especially appliance customization, easier. In particular, this means that rPath spends development resources primarily on things that are particularly useful for customization and appliance deployment. This will make rPath Linux 2 a more compelling and useful platform not only for building new appliances (both software appliances and virtual appliances) but also for building complete operating systems, such as Foresight Linux.

We will maintain separately information on migrating your appliances to rPath Linux 2

What Hasn't Changed

We are building on the strengths of rPath Linux 1. You can continue to expect timely and relevant security updates, bug fixes, and a stable library and feature set. As in rPath Linux 1, we will occasionally update to a more recent stable upstream kernel in order to provide support for recent hardware. And, of course, the fact that rPath Linux 2 is built with Conary means that you can continue to build appliances and custom operating systems around the components that rPath Linux 2 provides.

Significant Changes and New Features

Major software versions

  • Toolchain follows a stable, maintained upstream
  • glibc 2.5
  • Core portions of GNOME 2.20.x required for building the anaconda installer
  • xorg 7.3, installed in system directories
  • Apache httpd 2.2.x
  • Recent anaconda installer
  • General updates to recent stable versions of packages

Major technological changes

  • The entire distribution has been rebuilt from scratch, incorporating many Conary enhancements into the default package set (see RPL-752). These enhancements include:
  • Packages will now include "file:" provisions for files in binary directories. This will allow requiring, for example, /bin/sed instead of sed:runtime since other packages might provide /bin/sed
  • Docs in /usr/share/doc/ will now be part of :supdoc, not :doc, to allow for group writers to include man/info packages and not other documentation.
  • Group structure modified, and other changes made to better support making small appliances based on rPath Linux - see rPath Linux 2 Group Structure
    • This includes flavors of groups that do not include things like development libraries that are generally not useful for appliance instances.
  • Compile with --fstack-protectorand FORTIFY_SOURCE=2, link with GNU hash and -O1, and use -fPIE for some key executables.
  • syslinux is the default bootloader

A major exceptions to the "most recent stable versions" rule includes Python 2.4:

  • We want to be compatible with other users of mod_python that use Python 2.4.
  • We have enhanced python dependencies to list runtime major version, and should have one release with that modification before updating to Python 2.5.
  • Updating other Python-using packages will generally be constrained.
  • Minor incompatibilities between Python 2.4 and Python 2.5 need to be handled by external consumers (outside rPath Linux, and thus outside of our control and testability) of Python, and we want to give time for that to occur.

In general, we will be considering general compatibility with other distributions that have large market presence which use similar glibc, gcc, apache, etc. versions. Therefore, some critical system libraries may be maintained at a recent-but-not-very-latest version, particularly when there are soname conflicts.

Other changes we made include:

  • Removing unnecessary patch sets from many packages to make them follow upstream more closely. Exceptions to this rule tend to be for one or more of the following reasons:
    • Keeping compatibility with common practices that we have implemented (such as user-private groups)
    • Keeping library compatibility with some other distributions where it is important to do so (for example, if there are major proprietary applications that link against those libraries).
    • Having a maintained software stream for software that is not really being maintained upstream.