Changes between Version 115 and Version 116 of SummerOfCode


Ignore:
Timestamp:
May 23, 2009, 4:52:08 AM (12 years ago)
Author:
raimue (Rainer Müller)
Comment:

Revert to revision 113 due to accidental changes

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode

    v115 v116  
    99Information about the past years can be found at SummerOfCodeArchive.
    1010
    11 == Projects 2009 ==
    12 
    13 The following students have been accepted for this year:
    14 
    15  * [wiki:enl Dmitry Gorbik], Logging
    16  * [wiki:juanger Juan Germán Castañeda Echevarría], GUI
    17 
    1811== Applications for SoC ==
    1912
    2013=== General Info ===
    2114
    22 Applications must be done online, on 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]. Consult the official [http://code.google.com/opensource/gsoc/2009/faqs.html#timeline timeline] for any specific dates.
     15Applications must be done online, on 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]. Student applications must be submitted by '''April 3, 19:00 UTC'''. The official [http://code.google.com/opensource/gsoc/2009/faqs.html#timeline timeline] should be consulted for the other dates.
    2316
    2417There 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.
     
    5750==== Dependencies ==== #dependencies
    5851
    59 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 f
     52This 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).
     53
     54Classification: very challenging task[[BR]]
     55Programming languages: Tcl and C[[BR]]
     56Potential mentors: TBD
     57
     58==== Logging ==== #logging
     59
     60Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a 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.
     61
     62This 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.
     63
     64Classification: medium task to relatively challenging[[BR]]
     65Programming languages: Tcl and C[[BR]]
     66Potential mentor: blb
     67
     68==== Configuration files handling ==== #configfiles
     69
     70MacPorts has no way to track configuration files. Currently if a configuration file is part of a port it will get overwritten on every upgrade which makes it less useful. At the moment, many ports only install default configuration files and the user has to copy it to the original location. But this always requires manual action and the user is not informed of updates in this configuration file.
     71
     72For this task, investigate how other package management systems handle this. Find the best way to support it in MacPorts and implement it. See also #2365.
     73
     74Classification: easy to medium task[[BR]]
     75Programming languages: Tcl[[BR]]
     76Potential mentor: raimue
     77
     78==== Scan for broken dynamic libraries for rebuild ==== #rev-upgrade
     79
     80Upgrading 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.
     81
     82{{{
     83port rev-upgrade [portname]
     84}}}
     85
     86If you are familiar with Gentoo, this would be the equivalent of the revdep-rebuild command. See #17473 for more information.
     87
     88Classification: easy to medium task[[BR]]
     89Programming languages: Tcl[[BR]]
     90Potential mentor: raimue
     91
     92==== MacPorts Port for self-management ==== #self-management
     93
     94The MacPorts port should be the source for updating a user's MacPorts
     95installation.
     96
     97Currently 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
     98
     99Classification: challenging task[[BR]]
     100Programming languages: Tcl and C[[BR]]
     101Potential mentor: blb
     102
     103==== Check dependencies after destroot ==== #depcheck
     104
     105MacPorts 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.
     106
     107A new phase would be created which is to be run after the destroot phase to verify files.
     108 * 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.
     109 * It will report broken symlinks, e.g. those pointing to the destroot
     110Any problems found should be reported.
     111
     112This 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.
     113
     114Classification: medium task[[BR]]
     115Programming languages: Tcl and C[[BR]]
     116Potential mentor: raimue
     117
     118==== Binaries ==== #binaries
     119
     120MacPorts 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.
     121
     122See also [wiki:MPAB MacPorts AutoBuild].
     123
     124Classification: relatively challenging to challenging task[[BR]]
     125Programming language: Tcl[[BR]]
     126Potential mentors: TBD
     127
     128==== Graphical user interface ==== #GUI
     129
     130Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users. See also [http://ihack.us/2008/03/24/building-a-gui-for-macports/ drernie's post] about MacPorts GUIs. The  [http://trac.macports.org/wiki/armahg MacPorts.Framework] and [http://trac.macports.org/browser/users/rhwood/Pallet Pallet] projects contain some of the already done ground work for building such a GUI. Also see [wiki:MacPortsGUIFAQ GSoC 2009 MacPorts GUI "FAQ"] for some useful details on what this project would entail.
     131
     132Classification: major task[[BR]]
     133Programming languages: Tcl and any other language for the GUI part (e.g. ObjC)[[BR]]
     134Potential mentors: armahg
     135
     136==== Images (Pkgview, depot-to-depot dependencies) ==== #images
     137
     138MacPorts 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).
     139
     140Classification: challenging to very challenging task[[BR]]
     141Programming language: Tcl[[BR]]
     142Potential mentor: TBD
     143
     144==== Portfiles ==== #Portfiles
     145
     146Sweep 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.
     147
     148Classification: medium task[[BR]]
     149Programming language: Tcl[[BR]]
     150Potential mentor: TBD
     151
     152==== Shell Environment ==== #shell-environment
     153
     154Add 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`.
     155
     156This task alone is most probably not enough for the whole Summer Of Code.
     157
     158Classification: easy task [[BR]]
     159Potential mentors: raimue
     160
     161==== Automatic testing ==== #testing
     162
     163MacPorts 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.
     164
     165Classification: relatively easy to very challenging[[BR]]
     166Programming languages: Tcl, C[[BR]]
     167Potential mentor: raimue
     168
     169==== MacPorts Web Application (MPWA) ==== #mpwa
     170
     171A very good start has been made on a Web Application for MacPorts to serve as a basis for easier user submission and maintenance of ports, not to mention monitoring of port build status, browsing of ports, etc. This work is known as MPWA and is written in Ruby on Rails. This task is to complete the work on MPWA so that it is usable for day to day usage by the MacPorts community. Work is needed on user credentials and authentication, port dependency  integration, port submission and tracking, etc. This is a very exciting project and can help MacPorts scale to support a larger community.
     172
     173Read more about the [source:contrib/mpwa/doc MPWA design and model] and look at the [source:contrib/mpwa/ existing code].
     174
     175Classification: moderate, with good follow through vision, and architecture required[[BR]]
     176Programming languages: Ruby, perhaps a bit of Tcl[[BR]]
     177Potential mentor: jberry
     178
     179=== Additional tasks ===
     180
     181==== Task A1: Ports ====
     182 * Porting of additional packages to MacPorts
     183 * Cleanup and/or remove obsolete ports
     184
     185Classification: medium task[[BR]]
     186Potential mentors: TBD
     187
     188==== Task A2: Documentation and Website ====
     189 * Improve MacPorts documentation
     190 * Improve MacPorts website
     191 * Custom Trac plugins
     192
     193'''Note''': Pure documentation proposals are not allowed by Google.
     194
     195Classification: minor task[[BR]]
     196Programming languages: php, python[[BR]]
     197Potential mentors: TBD