Foss lect 15 1 11

FOSS Lecture Notes

Sat Jan 15 10:22:37 IST 2011

Also contains review of Thursday's session.

---

About the Free Software Ecosystem:

- Communities, Projects, Upstream/Downstream:

Let us take the example of the hyphenation project (Open Office Hyphenation for Indian languages). This project was started by Santosh Thottingal. Just like any other free software project, it does not need permission from any authority to get started.

Hyphenation project involves creating hyphenation rule dictionaries for Indian languages for use in OpenOffice. To elaborate, hyphenation involves deciding rules which dictate in what manner a word is to be broken and appended with a hyphen (-) at the end of the line. There are algorithms to be written in order to make this happen in an efficient manner so that the text is more readable. This feature is currently not directly available in OO for Indian Languages. Therefore SMC has started this project.

So there is an SMC (Swatanthra Malayalam Computing) Community as well as a hyphenation project community inside it. This can be considered a representative of Free Software Project Communities. Like most communities, the SMC community. - Consists of volunteer developers - Has its own website/wiki to provide information on its activities and projects. - It has an online code repository (in this case hosted by Savannah), - Mailing list for communication between members - Bug tracking system (again, Savannah)

               As shown below in fig.

In this way there are thousands of communities including OpenOffice.org, Debian itself, GCC, Vim, Mozilla and even the Linux kernel.

The community software is maintained by volunteer developers. The norms for joining various communities are different. Debian, for instance has a very strict code based on amount of contribution and trust between developers.

Suppose someone builds a hyphenation package for use with a language that was hitherto unsupported and wants to include it in the hyphenation project. He will have to contact a hyphenation developer or the owner to review the package and if it is acceptable, according to the quality norms, then the owner will include the fix in the package of that software.

This counts as 'a fixed bug' or extension. Hence, it is ethically necessary for the fix to be sent upstream (i.e. in this case, to the Open Office project community. Now the Open Office community may or may not accept the package. However, it still provides it as an extension, which an average user can use to patch his older version of Open Office. This is an advantage and disadvantage of the free software model. That is, the community has the choice of use and so does the individual user who may want to use a piece of software that the community does not want to officially support.

So the sending of a hyphenation package created by Shravan, to Santosh (owner of hyphenation project) and then in turn from Santosh to the OO project is an example if 'sending upstream'.

In this way the software can be sent from OO to Debian and from there it can go to other derivative projects (projects based on Debian) like Ubuntu. Since Ubuntu bases itself on Debian, this transfer from Debian to Ubuntu community is called 'downstream'.

               Whole concept can be understood by fig below.

- Distributions :

All the free software projects need to run on some operating system kernel. Many free software are available for use on Windows too. But there is a need for a GNU operating system. (GNU/HURD aims to be this kernel but it is under construction). In the meantime GNU/Linux was started and it has become the de-facto kernel for free software. (Other working kernels include *BSD derivatives, but BSD licence is more permissive than the GPL).

Therefore most of the Free Software runs on Linux. All the applications and the kernel itself are available in source code form.

A user can obtain compile and build a customised system from source. But this is not feasible for naive home users. Also, groups of users may have similar needs. This gives way to the concept of distribution.

A distribution is also maintained by a FOSS community. They take the source code from the different project source repositories, and make it available in the form of an installable package. This package includes the binary (note: not source) of the software, a script and some other information needed for installation. A distribution also provides a package management tool to take care of installation, dependencies and other low-level issues that arise.

In this way different applications, desktop environments, file-systems, networking support, Linux kernels can be provided by the distribution in a nicely packaged form, which is also easily transferrable over the net, on CD or USB stick.

Each distribution has its own mix of packages and its own repository of packages.

Packaging is the core of the distribution.

Package formats may differ in name and layout but all do the same thing. The two most broadly used ones are rpm from Red Hat and deb from Debian.

You can make your own package format.

- Repos and extensions/updates:

A distribution community has to make sure that: - It maintains an up-to-date and bug free repository of packages. - It provides downstream packages to fix bugs that it may have received (from anywhere), if they meet quality standards. - Often the package managing tool itself provides an option to update the system.

Continuing the example, with respect to Debian and Ubuntu, if you want to install the hyphenation package for your native language, the first thing you do is check with the package manager on your distribution. In this case -

apt-get install openoffice.org-hyphenation-mylanguage

If this fails it will tell why the failure has occurred. In this case it is the fact that the package does not exist. So what can one do?

Answer: wait for the Debian community to make the package or do it yourself or install from source. Consider the first option:

- How a bug is fixed/reported or a package added:

As mentioned before the community will have a bug tracking system. A distribution community like Debian may also have a package request system. WNPP does this job for Debian. (WNPP=Work Needing and Prospective Packages).

On this website you can put mainly two kinds of requests:

- Request for Package (RFP): This means that you request the community to provide a package for the said s/w. - Intent to package (ITP) : This means that you declare that you intend to package it for the community.

We saw how the WNPP system works with an elaborate system of emails. It was observed that for Hyphenation Kannada package, Santosh put up an ITP and Shravan took that up. Likewise Sanaa took up the package for Bengali.

Similarly there was an RFP for brl-cad, which so many people from around the world had taken up and abandoned (:P). Debian believes in pure and bug-free code, even smallest of lintian warnings are not tolerated. There are also packages which the original maintainer cannot carry on with due to some reason. They can be transferred to another person.

- Getting the package into your Distro:

But even if Shravan completes the Hyphenation package for Kannada and Santosh approves it, it will take more than that for it to get into the Debian repo.

(Introduction to the Debian community. Doocracy and consistent contribution. These concepts were only touched upon lightly here but they are a large topic, so we'll consider them later.)

The checkout rights for the package are with the official Debian Developer (DD). In this case Santosh/Shravan will have to get in touch with an official DD (eg: Kartik Mistry) and the DD will review the package. If it meets the quality norms of Debian (and these really are strict), then it will be added into the Debian repository.

One could add it more easily into the Ubuntu repo maybe [correct me]. The point here is it all depends on the distro community's policy about packages.

Another example is that NVIDIA drivers (non-free) will never find their way into a Debian repo but might be there in an Ubuntu repo. (User still has the freedom to use these drivers with Debian but due to the inherent paradox in that, Debian does not officially approve this.)

              Above process can be understood by fig. below

- We also started making Hyphenation Packages: - New developers should use the New Maintainers' Guide while more experienced ones might use the Debian Policy Guide - We followed the instructions in it and created the control file for the hyphenation package.

- One important point: Build dependencies are only those things that you absolutely need during the time that the package is getting built. The normal dependencies are runtime dependencies without which the software will not run.

---

Homework: - Complete the packaging of at least one Hyphenation package. - All those who were absent for the first session must learn Git and make a repo for class notes taken personally by you. - All should start reading the course ebooks - All those who have not got a mentor should find one.