Changes between Version 75 and Version 76 of SummerOfCode


Ignore:
Timestamp:
Feb 16, 2009, 2:52:06 PM (15 years ago)
Author:
raimue (Rainer Müller)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode

    v75 v76  
    4949=== Core Tasks ===
    5050
    51 ==== Task 1: Dependencies ====
     51==== Dependencies ====
    5252
    5353This 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).
     
    5757Potential mentors: jberry
    5858
    59 ==== Task 2: Python Group ====
     59==== Python Group ====
    6060
    6161Improve Python [source:trunk/base/src/port1.0/resources/group group] code.[[BR]]
     
    6868Potential mentor: raimue
    6969
    70 ==== Task 3: MacPorts Port ====
     70==== MacPorts Port ====
    7171
    7272The MacPorts port should be the source for updating a user's MacPorts
     
    7979Potential mentor: rhwood, jmpp
    8080
    81 ==== Task 4: Binaries ====
     81==== Binaries ====
    8282
    8383MacPorts 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.
     
    8787Potential mentors: wms, jmpp
    8888
    89 ==== Task 5: Graphical user interface ====
     89==== Graphical user interface ====
    9090
    9191Come 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.
     
    9595Potential mentors: drernie
    9696
    97 ==== Task 6: Images (Pkgview, depot-to-depot dependencies) ====
     97==== Images (Pkgview, depot-to-depot dependencies) ====
    9898
    9999MacPorts 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).
     
    103103Potential mentor: wms
    104104
    105 ==== Task 7: Root privileges ====
    106 
    107 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.
    108 
    109 Classification: medium task[[BR]]
    110 Programming language: Tcl, C[[BR]]
    111 Potential mentors: raimue
    112 
    113 ==== Task 8: Portfiles ====
     105==== Portfiles ====
    114106
    115107Sweep 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.
     
    119111Potential mentor: wms
    120112
    121 ==== Task 9: Mirroring ====
    122 
    123 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.
    124 
    125 Classification: medium task[[BR]]
    126 Potential mentors: wms
    127 
    128 ==== Task 10: Shell Environment ====
     113==== Shell Environment ====
    129114
    130115Add support for 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`.
     
    133118Potential mentors: rhwood, jmpp
    134119
    135 ==== Task 11: Automatic testing ====
     120==== Automatic testing ====
    136121
    137122MacPorts 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.
     
    141126Potential mentor: wms
    142127
    143 ==== Task 12: Logging ====
     128==== Logging ====
    144129
    145 Currently 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, possibly through the interaction with a server side application like MPWA that could consume these logs (read below). A more detailed draft of this task can be found on the LoggingProposal page.
     130Currently 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, possibly through 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.
    146131
    147132Classification: medium task to relatively challenging[[BR]]
     
    149134Potential mentor: jmpp, wms
    150135
    151 ==== Task 13: MacPorts Web Application ====
     136==== MacPorts Web Application ====
    152137
    153138A 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.