= Google Summer of Code = [[PageOutline]] This is the main tracking page for MacPorts' Google [http://code.google.com/soc/ "Summer of Code"]. [[Image(http://code.google.com/images/GSoC2011_300x200.png, 300, link=http://www.google-melange.com/, title=Creative Commons Attribution-Noncommercial-No Derivative Works 3.0)]] Information about the past years can be found at SummerOfCodeArchive. == Applications for SoC == {{{ #!comment #!div style="clear:both; display:block; width: 75%; margin:0 auto; background-color: lightgreen; border: 2pt solid; font-weight:bold; text-align: center; font-size:120%;" Application period has opened! [[BR]] Apply now for Google Summer Of Code 2010! [[BR]] [http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/macports MacPorts at GSoC website] }}} === General Info === For future reference you may check the [http://socghop.appspot.com/ Google SoC website]. You will find more information on their page on [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students]. The official [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline timeline] should be consulted for the other dates. 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 MacPorts. Motivated students do not necessarily need to know Tcl language beforehand, especially if they already know several script languages such as Python, Ruby, PHP or Perl. === For the MacPorts project === The best way to apply is to first make contact with us, either by sending a mail to the MacPorts developer [http://lists.macosforge.org/mailman/listinfo/macports-dev "mailing list"], to the potential mentors listed below, or to IRC members on #macports on [http://freenode.net/ FreeNode]. What we expect from students for their applications: * Write your own abstract and proposal, copying text from this idea page is not enough. * Show us that you fully understand your task and know what you want to do over the summer. * At best, include a short weekly roadmap covering how you would work on the task. What you should do before handing in an application: * Get familiar with the MacPorts project resources. Especially [GetMacPortsSource check out the code] and [http://guide.macports.org read the guide]. * Read the [http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html Tcl Tutorial] * Subscribe to the mailing lists [http://lists.macosforge.org/mailman/listinfo/macports-dev macports-dev] and [http://lists.macosforge.org/mailman/listinfo/macports-users macports-users] if you do not already read them. Don't be too shy to post. * '''Get in contact! ''' Most important is to discuss your contribution ideas with potential mentors by e-mail, on the MacPorts development list or the IRC channel before applying. == Mentors == The following committers have agreed to be mentors for SoC 2010 (append @macports.org for e-mail) ||'''Name''' ||'''Email''' ||'''Area''' || ||[wiki:juanger Juan Germán Castañeda Echevarria] || juanger || GUI, MPWA || ||[wiki:perry Perry Lee] || perry || || ||[wiki:raimue Rainer Mueller] || raimue || Administrator, config files, rev-upgrade, depcheck || ||[wiki:snc Jeremy Lavergne] || snc || || ||[wiki:wms William Siegrist] || wms || Backup Administrator || == 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. Please note that this list is absolutely '''not exclusive'''! If you have any idea about what you want to see improved in MacPorts, you are free to propose this as your own project. In any case, we recommend to talk to mentors before writing your application. === Core Tasks === ==== Binaries ==== #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. See also [wiki:MPAB MacPorts AutoBuild]. Classification: relatively challenging to challenging task[[BR]] Programming language: Tcl[[BR]] Potential mentors: TBD ==== Scan for broken dynamic libraries for rebuild ==== #rev-upgrade Upgrading any port can naturally break its dependents if using dynamic libraries. The only way to fix this is currently rebuilding all dependents, no matter if necessary or not. MacPorts should get a new command to scan installed dynamic libraries and binaries for linker errors and mark the corresponding port for rebuild. After checking all files, broken ones should get rebuild in the correct order. Probably it has to do the check again after each set of rebuilds. {{{ port rev-upgrade [portname] }}} If you are familiar with Gentoo, this would be the equivalent of the revdep-rebuild command. See #17473 for more information. Classification: easy to medium task[[BR]] Programming languages: Tcl[[BR]] Potential mentor: raimue ==== Dependencies ==== #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[[BR]] Programming languages: Tcl and C[[BR]] Potential mentors: TBD ==== Check dependencies after destroot ==== #depcheck MacPorts currently has trace mode to check which files are accessed during build and if they are in the dependency chain. This requires injecting the tracelib in all code that is run and interception all open calls and make checks on the pathnames which slows down the procedure. This task is about creating another feature for verifying the dependencies of a build. A new phase would be created which is to be run after the destroot phase to verify files. * It would iterate over all binaries and dynamically linked libraries in the destroot which are going to be installed and check the recorded paths against the dependency chain. * It will report broken symlinks, e.g. those pointing to the destroot Any problems found should be reported. This would be great to do a quick check if the dependencies are met without the effort from trace mode. It could also help to identify unnecessary dependencies. If this actually runs fast enough it could as well be enabled by default, although it should only be necessary for maintainers. Classification: medium task[[BR]] Programming languages: Tcl and C[[BR]] Potential mentor: raimue ==== MacPorts Port for self-management ==== #self-management The MacPorts port should be the source for updating a user's MacPorts installation. Currently the MacPorts port is used to build the .dmg installer for MacPorts that is used for the initial installation of MacPorts, and port uses the "selfupdate" mechanism for maintaining the MacPorts installation. The selfupdate mechanism is (at least not documented as such) not accessible through the MacPorts API and does not use the MacPorts mechanisms for maintaining ports Classification: challenging task[[BR]] Programming languages: Tcl and C[[BR]] Potential mentor: TBD ==== Perl modules integration from CPAN ==== #cpan2port There has been [browser:contrib/cpan2port an attempt] to write a script for automatic generation of Portfiles from CPAN. This would simplify the maintenance of Perl modules in MacPorts. Revive this project and finish the script or rewrite it. Resources: * http://www.gentoo.org/proj/en/perl/g-cpan.xml * http://search.cpan.org/~bingos/CPANPLUS-0.9001/bin/cpan2dist * http://packages.debian.org/stable/dh-make-perl Classification: easy to medium task[[BR]] Programming languages: Perl and probably Tcl[[BR]] Potential mentor: TBD ==== Automatic testing ==== #testing MacPorts project currently includes a [source:trunk/base/tests 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[[BR]] Programming languages: Tcl, C[[BR]] Potential mentor: raimue ==== Portfiles ==== #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[[BR]] Programming language: Tcl[[BR]] Potential mentor: TBD ==== Shell Environment ==== #shell-environment Add support for providing basic and port-provided environmental services to users in the `~/.profile`, `~/.cshrc`, and `~/.xinitrc` files, so that instead of manipulating the user's .profile to modify certain paths, the installer could append "`source /opt/local/etc/bash.rc`" to the end of a user's .profile file and that bash.rc would source all the files in `/opt/local/etc/bash.d`. This task alone is most probably not enough for the whole Summer Of Code. Classification: easy task [[BR]] Potential mentors: raimue === Additional tasks === ==== Task A1: Ports ==== * Porting of additional packages to MacPorts * Cleanup and/or remove obsolete ports Classification: medium task[[BR]] Potential mentors: TBD ==== Task A2: Documentation and Website ==== * Improve MacPorts documentation * Improve MacPorts website * Custom Trac plugins '''Note''': Pure documentation proposals are not allowed by Google. Classification: minor task[[BR]] Programming languages: php, python[[BR]] Potential mentors: TBD {{{ #!comment # Listing already done tasks here, maybe parts of this could spin-off a new project idea # Done 2009 ==== Logging ==== #logging Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a build is attempted but an error keeps it from completing, there's no way to track the problem other than the build progress that was output to the terminal, if verbose mode was requested in the first place. Otherwise, the build environment has to be pruned and the build attempted once again to even get a look at the precise error message. This is particularly problematic when automated builds are attempted, since there's usually no one around to have a look at the failure spew. An infrastructure to remedy this situation and endow MacPorts with a rich set of logging capabilities has to be developed to open up the door to true automated build runs of large sets of ports and thus to packaging of binaries, since with logging we'd have a fully reliable way of catching, reporting and processing of all sorts of fetch/configure/build/destroot/install/etc errors. This could be extended with the interaction with a server side application like MPWA that could consume these logs (read MPWA proposal). A more detailed draft of this task can be found on the LoggingProposal page. Classification: medium task to relatively challenging[[BR]] Programming languages: Tcl and C[[BR]] Potential mentor: blb }}} {{{ #!comment # Removed ideas which do not fit to our plans anymore # Will be obsolete and no longer be possible with the images-and-archives branch ==== Images (Pkgview, depot-to-depot dependencies) ==== #images 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[[BR]] Programming language: Tcl[[BR]] Potential mentor: TBD }}}