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 :

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 softwarelicenses.

Comments

Hey!! GPL license does not require copyright assignment to FSF. FSF would
like to have the copyrights assigned to them, for every project under the
FSF/GNU umbrella, so that it is easier to control the code. Say tomorrow, you
want to change the license from GPLv2 to GPLv3. With individual copyright
holders on the same project, you need everyone's agreement. With a single
entity owning the copyright, it becomes easier.