Background assumptions::
o. A clean ubuntu hardy installation.
o. Some familiarity with command-line basics.
o. Have installed pbuilder.

That done, we can continue...

What is PACKAGING?

If you have ever used the apt-get or aptitude {Aaron has a nice writeup on aptitude Vs. apt-get} command : "sudo aptitude install <packagenames>"  on your Debian/Ubuntu system you used a tool that automatically installs a packaged software on your system. This would automatically pull all the dependencies for your Linux system to run smoothly. It saves you the pain of having to install software manually by pulling code in a tar.gz folder, extracting, etc...

Secondly, when you download a source package from a Debian/Ubuntu "deb-src" repo, its already a debian package.i.e the source files have been placed in a suitable directory tree, appropriate configuration files have been added, and the package contains scripts to help with the building and installation of the package. This is what allows you to just install from source with "apt-get -b source some-package-name" as mentioned before.

This post is different. As in, its not a path of least resistance (packaging an existing debianized package for Ubuntu). This is about creating a binary package from a source package, with customization, modification, or other tedious trouble. To do so, you do the following :

Wikipedia says,

The Debian build toolchain is a collection of software utilities used to create Debian source packages (.dsc) and Debian binary packages (.deb files) from upstream source tarballs.

These tools are used in the Debian project and also in Debian-based distributions such as Ubuntu.

One of the first steps was creating a .dsc as outlined at  https://wiki.ubuntu.com/PackagingGuide/Python

I had already pulled the stable source from LP [bzr branch lp:systers] but noticed that none of the files had copyright or license notices. I also had a number of questions on patching the current systers stable branch for releases and another part of the project as mentioned on the wiki was to work with the MM 3.0 port team. So I requested an upstream MM core-dev to comment on the following:

  • Q0. Currently systers runs only on Ubuntu-Hardy with python2.5 and systers has the habit of working only with ubuntu- LTS releases, hence Lucid could be the porting target.  I feel the tasks involved are -- convert  all .py programs compatible to python  2.6 or 2.7;  carry out code changes if any on the 2.6 or 2.7 .py files to make them work on lucid or Hardy , make package and test the package.
  • Q1. Currently systers code uses python2.5 and I'd like to know if it has to run/port compatibly on Lucid would that involve converting code to python2.7 (or python2.6)? That seems like a large task so I'd like to hear your comments. 
  • Q2. Would it involve making these python programs of systers which is currently compatible with 2.1.10 to be made compatible to mailman 3.0-- I'm not sure how different MM-2.1.10 is from MM-3.0 and assume this involves changes in code.  So what does working with the MM 3.0 port team entail?
  • Q3. According to the debian manuals the existing stable branch should contain licences for all files, to be packaged since GNU-Mailman would require this. Currently none of the stable branches or code fixes pulled from the systers repo have any license files. Am I supposed to contact the individual authors (I dont know them all) or should I just ask Jennifer/Robin ?

The reply I got was lucid (could not resist a pun) and in sum, I'd heard some of the packaging stuff before (in Debian? or was it in Ubuntu?):

  • o. Core-devs dont usually work on maintaining non-mainline stuff unless it's their own. So if you want your "feature-changes-patch" included in upstream, you'd have to be willing to maintain them long-term and that would involve a large commitment. If its not in mainline upstream, there is nobody to coordinate packaging or patches. As the developer of your "feature-changes-patch", its your baby which you should be willing to test and maintain each time mainline changes.
  • o. Ubuntu packaging of Mailman 2.1 introduces some bugs -- best compiled from source. Bringing another package (mailman-systers?) for an existing upstream package within Ubuntu could be an issue.
  • o. Mailman 2.1 and Mailman 3.0 are *entirely* different code bases. That means these wonderful systers feature changes would have to be re-implemented, not ported. Porting (as I asked above in Q0, Q1,Q2) would involve moving between python versions and this changes so many things when you are moving between two OS releases (in this case, Ubuntu hardy and lucid). Besides MM3.0 (in alpha stage) was an entirely different code base compared to 2.1 which is in feature freeze.
  • o. While it would be better to contribute code directly to MM3.0 ...BUT... using the existing code raises the license issues in Q3 above. This is something I cant answer as "legalese" is beyond me. Technically, all GPL code (for a FLOSS project) requires authors be willing to assign their work to the free software foundation, as explained in the gnu-licenses page: http://www.gnu.org/licenses/why-assign.html. IIRC, Ubuntu and Debian would require the license.txt file for packaging too. There is a list of FSF approved software licenses.