Linux distribution integration

Summary

• OSAF should support distribution integration because it will increase adoption and lower in-house packaging effort for Linux.
• OSAF will work through distribution representatives who will do the actual uploading of new Chandler releases into the distro's repository.
• Chandler will need some build modifications to support distro-provided compilers, python, and libraries.
• Integration will first happen via the "unofficial" repositories such as DAG, then proceed to full integration in the official distribution repositories.

Background

Software packaging for Linux (and other Unix-like operating systems) is different from Windows and Mac packaging. Windows and Mac packaging virtually requires binary, "one click" packaging, while Linux software is more successful when it is integrated into the various Linux distributions.

Since there are so many distributions, it is infeasible to support them all within OSAF. Even if it were possible to produce binary releases for a few dozen distribution/version combinations, doing so is undesirable for these reasons:

• Duplication of effort because distributions will work to package OSAF software regardless of OSAF-provided binary releases
• Perception of a "difficult install" because most users prefer to use their distribution's mechanism to install, config, upgrade, and uninstall software.
• Lower adoption rates because of users who choose not to go through the OSAF installation procedures
• Distribution integration is the standard mechanism for open-source software distribution in the Linux community

There are clear costs to supporting distributions directly. OSAF can expect problems related to not using exact versions of libraries. OSAF can expect problem reports that are really distro problems.

Integration mechanism

Linux distributions are typically run by a community or other party outside direct OSAF control and thus "integrating with Linux distributions" requires coordination with those outside parties.

Distributions will typically find a volunteer to coordinate between "upstream" (OSAF) and the distribution's repository of software packages. To package the software for a distribution, pristine copies of OSAF-provided releases of software will be used as a basis. A distribution-specific set of executable instructions will be written which automate the process of building and installing the software for that particular distribution.

OSAF has no inherit control over how this packaging is done. The distribution will use its own policies and standards to determine the location, naming, and wrapping of the OSAF software. The distribution may choose to modify (ie, patch) the software to address problems, modify behavior, or otherwise adhere to the distribution's policies.

Distribution integration is complete when installation for end-users uses the distribution-provided mechanisms:

• Debian, Ubuntu: apt-get install chandler
• Fedora: yum install chandler, apt-get install chandler

Furthermore, full integration will have a maintainer identified for each distribution who will update OSAF software in each distribution's repository when new releases are available from OSAF.

Distribution priorities

It would be nice if there was a simple way to determine the most "popular" Linux/Unix distributions. Then, OSAF could simply work to support distributions in order of their popularity. Because of the lack of centralized accounting, the wide array of available distributions, and the various environments in which distributions run (ie, desktop vs server configurations), no definitive list is possible.

In general, it can be said that it will be easier to get early OSAF software included into the official repositories of volunteer/non-commercial distributions (Debian, Fedora), than commercial distributions (RedHat, SuSE, Mandriva, Ubuntu).

Here is one ranking of priorities which serves as the "plan of record" but which is subject to modification.

Priority	Distro	Rationale
1	Gentoo x86	1) Heavy desktop usage 2) Early adopters; large portion of "latest and greatest" users 3) Easy integration, support for experimental packages, no need for binary builds
2	Fedora FC5	1) Large installed base 2) Leading RPM-based distro
3	Debian post-"sarge"	1) Lots of derived distros (over 100) 2) Leading DEB-based distro 3) Prerequisite for Ubuntu integration
4	Ubuntu post-"Badger"	1) Growing desktop distro 2) Easy followup to Debian "unstable" integration
5	Mandriva	1) Popular distribution
6	SuSE	1) Popular distribution

Support required

Best practices

Supporting distribution integration encompasses this (incomplete) list of best practices:

Practice	Status
Open software licensing	Good: All OSAF software is licensed under terms allowing for distribution and modification.
Official, numbered releases	Good: OSAF software has a release cycle and is available for easy download.
Standard build procedures	Debatable: Packagers will have some preference for a ./configure --prefix style configuration. They will want the software to untar into a private directory. They will work around these issues as needed.
Flexible build dependencies	Needs improvement: Build procedures generally support only OSAF-sourced versions of external libraries. Distros will want to build against their own versions if at all possible
Flexible installation procedures	Needs improvement: Distributions use a variety of directory structures and these structures should be supported. See "Distribution installation standards" below.
Packager support channel	Unknown: Distro packagers should have a defined channel to obtain "upstream" support. Bugzilla and dev are probably sufficient.
Unix API support	Debatable: There's no reason that Chandler couldn't build on other Unix-like environments such as FreeBSD, Solaris, Fink, and others. Build system support for non-Linux platforms would be time-consuming.

Distribution installation standards

Standard packaging for desktop Python applications in official distributions is typically something like the following structure:

• /usr/bin/chandler
• /usr/lib/python2.4/site-packages/chandler/*
• /usr/share/doc/chandler/*

Next steps

General distro support

1. Support distro-provided GCC/GCJ by splitting GCJ_HOME into GCJ_BIN and GCJ_LIB.
2. Support installation of Chandler and release dependencies into seperate combined directory (such as /tmp/chandler instead of $CHANDLERROOT/chandler).
3. Support Chandler build against distro-provided Python.
4. Support Chandler install into /usr/lib/python2.4/site-packages directory.
5. Create Xen-based virtual machine inside OSAF with installations of leading distributions.
6. Arrange for Chandler to build against outside PyLucene package.
7. Solicit, collect, and evaluate feedback from packagers with respect to packaging changes that would support easier distribution integration.
8. Support Chandler build against distro-provided SWIG.
9. Support Chandler build against distro-provided Twisted.

Gentoo integration

1. Work with Gentoo wxwindows herd to scrub ebuild and investigate Gentoo blockers to inclusion in portage (as ~x86, -*)
2. Package PyLucene for Gentoo separately.

Ubuntu and Debian "etch" integration

1. Solicit volunteer to contruct debian/rules file to build Chandler for Debian/experimental.
2. Port Debian debian/rules to Ubuntu Hoary.
3. Identify mechanisms and policies Ubuntu uses for inclusion of packages into Ubuntu's "universe" repository.
4. Obtain sponsor for upload of Chandler into Debian/unstable tree.
5. Set up relationship with maintainer of M2Crypto for Debian. Support to get regular maintenance of official release.
6. Package PyLucene for Debian separately.
7. Support migration of package into Debian/testing and eventually Debian/stable (etch).

Fedora FC5 integration

1. Work with the "DAG" unofficial repository to identify integration barriers, procedures, and platforms appropriate for inclusion.
2. Update Fedora release supported by OSAF.
3. Solicit sponsor to determine viability of incorporation of Chandler into Fedora community repository.
4. Set up relationship with maintainer of M2Crypto for Fedora. Support to get regular maintenance of official release.
5. Package PyLucene for Fedora separately.

Other distro integration

1. Contact representatives of SuSE to discuss blockers to integration.
2. Contact representatives of Mandriva to discuss blockers to integration.

Status of integration

No distributions currently include OSAF software in their official repositories.

Distro	Status
Fedora FC5	RPMs of Chandler available for download from OSAF. M2Crypto is available in FC2.
Fedora other	No OSAF software available
Gentoo	There are Chandler ebuilds available for Gentoo which would form the basis for integration into Gentoo's official repository.
Debian and derivatives	M2Crypto is available in Debian sarge and sid. No other OSAF software is listed in the Debian repository or Debian's database of unofficial repositories (http://www.apt-get.org).
SuSE	No OSAF software available in the RPM database of unofficial repositories (http://www.rpmfind.net).
Mandriva	No OSAF software available in the RPM database of unofficial repositories (http://www.rpmfind.net).

Work completed

1. Develop a spec file for FC5.
2. Autobuild inside OSAF for FC5.
3. Develop an ebuild for Gentoo.
4. Reopen Gentoo ticket for Chandler ebuild and contact Gentoo wxwindows Herd for review.