This page is oriented to that people that want a better understanding on how things work and how people can contribute to this project.

This is the first draft of this page so if you feel that information are not complete or they need to be improved send me a feedback.

Version control of IPv6 packages

As described in the main page we actually handle two different kind of packages and as well we use two different version scheme to avoid confusion.

Software that supports IPv6 in the upstream but disabled by the mantainer

This is the case for some packages like ssh. The simplest way of handling this situation is to add a .1 in the subrelease of the package itself. For example: foobar_1.0.3-5 that you can find in the normal Debian archive it becomes foobar_1.0.3-5.1 here.
Why did we choose this way??? Fair question. First of all we just enable a feature and we don't modify anything in the code. Second it makes the autobuilder working smoothly. So that for instance when a foobar_1.0.3-5.2 will be out our bounch of scripts will create a foobar_1.0.3-5.2.1 immediatly after.
The autobuilder is actually running only on i386. Sparc packages are still uploaded by hand. We are working on a script that can automate this procedure pushing the packages for different archs directly in this archive. When it will be ready and well tested, people that can spare some of their cpu time to build pkgs other than i386 and sparc will be really appreciated.
Are you aware of this kind of packages that are not present in this archive?? mail me immediatly and I will put them in the autobuilder scripts.

Software that does not support IPv6 and require manual patching

For this kind of software we agreed to use the packages name scheme proposed by h-yamamo ( http://www002.upp.so-net.ne.jp/h-yamamo/) in which he suggests to change barfoo_1.1.0-1 into barfoo_1.1.0-1.ipv6.rX so that it is possible to keep track of the patching level and gives a warning to people that the original code has been modified. Most of this software cannot be autobuilt since patches might not apply between different releases (or even subreleases) and this makes maintainance of this software a bit more complex. In few words it needs to be built manually at the first instance and then uploaded to the archive.
Are you an active mantainer of such kind of packages and you want them added to this archive??? Then no problems at all. Contact me and you will get proper instructions on how to upload directly to the archive.

Inclusion of third party packages

This is the case for some piece of software that is not maintained by us directly. We would love to involve this developers directly but in case of a negative response we will evaluate atleast if we can include their packages in the archive.

Responsibilities

There are no responsibilites and no warranties. Noone has enough resources to check all the software in the archive. Not even the autobuilt one. Use this archive at your own risk!