Google Summer of Code, 2007

This is the main tracking page for MacPorts/Google ​Summer of Code 2007. MacPorts was approved by Google as a ​mentor organization for Summer of Code 2007.

GSoC 2007 is now over. The MacPorts projects that were undertaken can be found on our ​organization information page on the SoC site. The rest of the information here is of primarily historical interest, though some of it may also be applicable to GSoC 2008.

Applying for SoC

Applications should be done online, on Google website. You will find more information on their page on ​Student Applications. Initial student applications ​must be submitted by 5 pm PDT, March 26th, 2007.

There are several things to consider. We are willing to support and mentor students who want to gain an experience by working on the macports project. We have many ideas for potential internship subjects, yet we are open to anything that is both interesting and relevant to the MacPorts project. Motivated students do not necessarily need to know Tcl language beforehand, especially if they already know several script languages such as python, ruby or perl.

The best way to apply is to first make contact with us, either by sending a mail to the MacPorts developer ​mailing list, to the potential mentors listed below, or to irc members on #macports on ​freenode.

Mentors

The following committers have agreed to be mentors for SoC (append @macports.org for e-mail)

• James Berry (base, general, ports) [jberry]
• James Cox (base, general, ports) [imajes]
• Paul Guyot (base, general, ports) [pguyot]
• Markus Weissmann (base, general, ports) [mww]

Tasks

This is a list of some potential tasks that student SoC members could undertake. These are just ideas, and while they express our current concerns, we are open to blue-sky projects related to MacPorts. We strongly suggest that you discuss your contribution ideas with potential mentors by e-mail, on the MacPorts development list or the irc channel before applying.

Core Tasks

Task 1: Dependencies

This task consists of implementing a new dependencies engine for MacPorts. The current dependency engine properly deals with installing packages, but it does not deal satisfactorily with dependencies on variants (and versions), uninstalling and upgrading. This very challenging task requires a complete formalization of the use cases (installation, upgrade, uninstallation) and of the user needs before any implementation, as well as a deep understanding of the dependency relations (required for fetching, building, configuring; static and dynamic linking; dependence at runtime).

Classification: very challenging task
Programming languages: Tcl and C
Potential mentors: pguyot, jberry, mww

Task 2: Python Group

Improve Python ​group code.
We currently have a lot of Python modules, which are built for Python 2.4. We now need a system to re-use port information about one python port to create Ports for Python 2.4 AND Python 2.5 (and possibly later versions). This though has to be made modular, so we can just re-use the description, etc. (if different versions of one module are required for different Python versions) or just re-use the whole information (checksums, etc.). This system will be interesting for other kind of subsystems, too, where different interpreters/virtual machines/compilers should be used.

Classification: medium task
Programming languages: Tcl
Potential mentor: mww

Task 3: Virtual "chroot"

MacPorts uses dynamic library injection code to control and monitor file system accesses of ports when they are compiled. This technique is used for the trace mode which is used to automatically figure out dependencies between ports. The proposed task consists in upgrading this mechanism to transform the trace mode (which reports) into a virtual chroot environment which will contraint ports to be compiled in a controlled environment. For example, if a port does not mention a dependency on the jpeg port, the configure script, the compiler and the linker will not see jpeg port binaries, includes and libraries. This task could extend up to defining virtual ports based on software installed with traditional MacOS X packages (for which list of files are saved in /Library/Receipts/). Part of the challenge includes the design of an efficient communication channel between the dynamic library and the Tcl code and a complete study of possible holes in this virtual chroot environment.

Classification: challenging task
Programming languages: Tcl and C
Potential mentor: pguyot

Task 4: Binaries

MacPorts project does not provide binaries yet (installation of software without compiling them). This project consists in working in concert (or cooperatively) with whomever does (virtual chroot) to setup a mechanism to automatically build packages, send reports on failures and implement a distribution mechanisms to allow users to fetch binary packages. This task could extend to support universal binaries, cross-testing (building on an intel box and testing on a powerpc box) and extending the livecheck mechanism to automatically send reports when ports are updated.

Classification: relatively challenging to challenging task
Programming language: Tcl
Potential mentors: pguyot, jberry, mww

Task 5: Graphical user interface

Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users.

Classification: major task
Programming languages: Tcl and any other language for the GUI part (e.g. ObjC)
Potential mentors: rhwood

Task 6: Images (Pkgview, depot-to-depot dependencies)

MacPorts implements what we call the Image mode where software are stored in a depot (e.g. /opt/local/var/db/dports/software/gawk/3.1.5_2/opt/local/bin/gawk). For the moment, this functions like an archive and files are hardlinked to their active location (/opt/local/bin/gawk). If port A depends on dynamic library B.dylib from port B, it actually links to /opt/local/lib/B.dylib. The idea of this task is to figure out a way for port A to be linked to the library in the depot and to work even if port B is not active. That is to say that if port foo depends on version 1.2.3 of port bar, it should be compiled and linked in such a way that it's wired to the depot location of bar, not the "activated" location. That will finally fix the fragility problem where deactivating port bar vers n-1 in order to install port bar vers n (because other things depend on n) won't also require breaking everything that relies on n-1. This mechanism also has additional advantages such as limiting the unavailability time to a minimum, especially when upgrading libraries every other package depends on (such as gettext).

Classification: challenging to very challenging task
Programming language: Tcl
Potential mentor: pguyot

Task 7: Root privileges

Implement facility to reduce need to execute macports as root, by adding facilities to mark ports as requiring root, by dropping root privileges where possible, and perhaps by keeping repository in per-user space.

Classification: medium task
Programming language: Tcl, C
Potential mentors: imajes, jberry, mww

Task 8: Portfiles

Sweep through all Portfiles and look for useful opportunities to add more built-in Tcl functions that make Portfiles more (usefully) terse, powerful, flexible or easier to write. I'm sure there is an entirely family of helper functions yet to be written here.

Classification: medium task
Programming language: Tcl
Potential mentor: mww

Task 9: Mirroring

Implement a mechanism and setup a system to mirror distribution files for MacPorts. This task consists in developing tools to automatically create and update mirror directories and will certainly require some rework of the code that fetches tarballs.

Classification: medium task
Potential mentors: pguyot, imajes

Task 10: Lint

Implement a style checking tool to process portfiles. This checking tool could either be based on existing Tcl code or the task could be extended to implementing a new parser for the Portfiles in C.

Classification: relatively easy
Programming language: Tcl or C
Potential mentor: pguyot

Task 11: Automatic testing

Macports project currently includes a ​test framework to test features of the infrastructure. However, the tests do not cover all the code and they are not executed on an automatic basis. This task consists of extending the test framework and could be broadened to develop a code coverage technology for MacPorts to make the infrastructure more robust to future changes.

Classification: relatively easy to very challenging
Programming languages: Tcl, C
Potential mentor: pguyot

Additional tasks

Task A1: Ports

• Porting of additional packages to MacPorts
• Cleanup and/or remove obsolete ports

Classification: medium task
Potential mentors: imajes, mww

Task A2: Documentation and Website

• Improve macports documentation
• Improve macports website (e. g. create a browseable list of ports, make man pages of ports available online)

Classification: minor task
Potential mentors: imajes, mww