Child pages
  • Prepackaging Fedora Commons 2.2.1 for Debian Etch
Skip to end of metadata
Go to start of metadata



This article has been moved from the archive and may be obsolete because of the recent work on Fedora Commons 2.2.X on Debian Etch and Fedora Commons 3 on Debian Etch. Comments would be appreciated if this article should be removed in favor of the other two articles or can be productively updated.

This page describes the outcome of and the effort put into the contruction of a Debian package of Fedora Commons 2.2.1, aimed to be installable on a standard Debian Etch system. It also briefly discuss the potential future of prepackaging Fedora for Debian.

This work was done at DTV and announced on the Fedora Commons users mailing list.

The intended primary audience for a Fedora Debian package are Debian system administrators keen to keep the number of software packages on a system to a minimum and perfectly happy with text-editor based (reasonably well documented) configuration experiences and the fact that they are themselves responsible for conducting necessary (and reasonably documented) adaptions of the configuration of any dependency packages.

The intended secondary audience for a Fedora Debian package are members of the growing Ubuntu user group (although they probably have a different profile than the average Debian Etch user and thus may not be so likely to be happy with the above), as Ubuntu is build on Debian.

The Debian package described below should be considered a prototype or a proof of concept.

The intention has been to investigate the extend to which prepackaging of Fedora can be done.

The first section below is intended for those willing to try to install Fedora on Debian Etch by the prototype package.

The second section is intended for those interested in knowing some things about how to prepackage Fedora for Debian. Perhaps because they would like to do it themselves.

The third section is intended for those thinking about the structure and nature of the Fedora code base, primarily in the context of allowing for such prepackaging (for Debian and/or for other distributions) in the future of Fedora.

Acquiring Fedora Commons 2.2.1 as a Debian package

Obtaining a functional Fedora on any system is beyond the scope of this page (see here for a description) and obtaining a functional Fedora specifically on a Debian Etch system is also not the purpose of this document (although I do recommend reading through this).

Obtaining a funtional Fedora on a Debian Etch system using the prepackaged 'fedora' Debian package is the focus, and it is a two-phased four-step process described below.

Every action decribed must be done as user root.

Phase 1: Installation


Using apt-get is assumed (using aptitude, dselect or synaptic or other package managers is an individual choice).

On a Debian Etch system, add

to /etc/apt/sources.list.

Run an update:

Install package 'fedora':

This will bring the Fedora code to the system.

General Tomcat Configuration

Fedora puts requirements on Tomcat that is not immediately met by the standard configuration of the Debian packaged tomcat5.5.

Those requirements and how to meet them are described in the documentation of Debian package 'fedora' (available in /usr/share/doc/fedora/README.Debian) and must be manually ensured before progressing further.

In addition, jdbc database connector jar(s) must be made available as common libs to tomcat. How to make the ones shipped with Fedora available is also described in the package documentation.

Phase 2: Activation


Initialising Fedora as a web application beneath Tomcat is done by running supporting script (installed with the package on the system):

Although currently no more than one Fedora instance can actually be served by the same Tomcat, this step is introduced as a seperate step for a potential future improved situation (where coexistence, and therefore the need to initialise many, becomes real), rather than being automatically conducted as a post-installation routine.

Webapp Specific Tomcat Configuration


to /etc/init.d/tomcat5.5.

As a consequence of keeping initialisation a seperate step, the necessary configuration of the Tomcat initialisation script (/etc/init.d/tomcat5.5) to make the initialised Fedora webapp actually work, becomes a seperate manual process.


Setup a suitable database with the necessary users and credentials and adjust the datbase connection parameters in the Fedora configuration file (located at /etc/fedora/fedora/fedora.fcfg) accordingly and restart Tomcat:

Hopefully, Fedora should then be running on http://localhost:8180/fedora/describe.

The Fedora configuration file may then be tuned for the needs of the repository.

Packaging The Current Fedora Commons 2.2.1 Code Base as a Debian Package

The process of packaging Fedora for Debian is based on the general guidelines for packaging, trying to comply as much as possible to the Debian Policy.

The necessary extra directories containing utilities, documentation and build description is avilable here and should be unpacked in the root of a Fedora Commons source distribution.

The tar archive does not change any file of the source distribution.

There are three principal obstacles for designing a smooth and regular packaging process of Fedora into a Debian package containing Fedora ready to install and use as a general software component.

Obstacle 1: Lack of automated install procedure

Unlike many other software source distributions, the Fedora source distribution does not contain an install procedure launchable from the commandline. The build tool ant is used, but no target for installation is present in the build.xml file. This makes automatic and non-dialog based prepackaging (for any target system) harder. Constructing a Debian package is highly automated/scripted and designed to allow the build process to be an automatic one

Current Workaround: When building the debian package, invoke the Fedora Installer, with a cookbook recipie for answers and subsequently move resources into their proper places in the Debian package.

Consequence: The build process is far from automatic, require both Tomcat and a database to be present on the build machine as well as it is vulnerable to human errors in the dialog with the Fedora Installer.

Obstacle 2: Non-compliance with FHS

When running Fedora, various resources are read from and written to locations beneath $FEDORA_HOME. It is unclear if and how these locations are changed. These locations are not compliant with the Filesystem Hierachy Standard implemented by Debian. On Debian, the location for log files, configuration files and other application resources are specified by the FHS and is (idealistically, at least) not to be changed by an installer. Debian packaging software also means ensuring that the software comply to FHS once installed.

Current Workaround: Script fedora_initialise will create all of the known resources
at their FHS compliant locations and symlink them back into $FEDORA_HOME.

Consequence: If their are files being written by the Fedora code beneath $FEDORA_HOME during execution which the packager of the prototype were unaware about, Fedora will fail on the target machine due to lack of permissions.

Obstacle 3: Mono culture

A running Fedora rely on the environment variable $FEDORA_HOME being set correctly before starting the Tomcat servlet engine. This will ensure that one - and only one - Fedora web application instance can exist beneath that Tomcat. As such, it is hard to consider Fedora a general software component (comparable to a database engine, a webserver, etc) that, once installed on a system, may be started on the system in as many instances as the system administrator may find useful.

Current Workaround: None found.

Packaging Future Fedora Commons Code Bases as Debian Packages

If prepackaging Fedora for Debian (and/or for other distributions) is to be done in the future, it is worth focusing on the quality of both the packaging procedure and the package itself, obtainable from the current Fedora 2.2.1 code base.

Or rather, on the limits of such quality due to the nature of the Fedora 2.2.1 code base.

The aforementioned obstacles represents some of the heaviest barriers.

Below are some recommendations on how to tackle these, seen from a Debian package builder and Debian package receivers point of view.

Some Changes To the Fedora Code Base For Debian Packaging To Become Easier

  1. Make it possible for an installer to comply with FHS (and other filesystem layouts): Introduce configurability of all filesystem resources used (configuration files/dirs read as well as log/data dirs for writing). Preferably in the same config file. Preferably to be placed at a tomcat-standard location relative to the fedora.war file and thus guarenteed to be found at tomcat startup regardless of which exact flavour of tomcat is being used.
  2. Allow automated installs: Introduce an install target in the build.xml so that "ant install" (allowing for options defining every location needed in order to put stuff in place) will actually install fedora onto a system in such a way that it will be runable assuming this system is (or will be) equiped with (any) tomcat and a(ny) suitable database.

Some Changes To the Fedora Code Base For Debian Packages To Become Better

  1. Split the Fedora client and the Fedora server into seperate code bases; package them individually.
  2. Allow coexistence of multiple Fedoras beneath same Tomcat: Get rid of the dependency on $FEDORA_HOME. The Activation Phase of the prototype Debian package described above will then become much simpler and intuitive.