Changes between Version 88 and Version 89 of SummerOfCode
- Timestamp:
- Mar 10, 2009, 3:04:42 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SummerOfCode
v88 v89 46 46 === Core Tasks === 47 47 48 ==== Dependencies ==== 48 ==== Dependencies ==== #dependencies 49 49 50 50 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). … … 54 54 Potential mentors: TBD 55 55 56 ==== Logging ==== 56 ==== Logging ==== #logging 57 57 58 58 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. … … 64 64 Potential mentor: TBD 65 65 66 ==== Configuration files handling ==== 66 ==== Configuration files handling ==== #configfiles 67 67 68 68 MacPorts 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. … … 74 74 Potential mentor: raimue 75 75 76 ==== Scan for broken dynamic libraries for rebuild ==== 76 ==== Scan for broken dynamic libraries for rebuild ==== #rev-upgrade 77 77 78 78 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. … … 88 88 Potential mentor: raimue 89 89 90 ==== MacPorts Port ====90 ==== MacPorts Port for self-management ==== #self-management 91 91 92 92 The MacPorts port should be the source for updating a user's MacPorts … … 99 99 Potential mentor: TBD 100 100 101 ==== Binaries ==== 101 ==== Binaries ==== #binaries 102 102 103 103 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. … … 107 107 Potential mentors: TBD 108 108 109 ==== Graphical user interface ==== 109 ==== Graphical user interface ==== #GUI 110 110 111 111 Come 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. … … 115 115 Potential mentors: armahg 116 116 117 ==== Images (Pkgview, depot-to-depot dependencies) ==== 117 ==== Images (Pkgview, depot-to-depot dependencies) ==== #images 118 118 119 119 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). … … 123 123 Potential mentor: TBD 124 124 125 ==== Portfiles ==== 125 ==== Portfiles ==== #Portfiles 126 126 127 127 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. … … 131 131 Potential mentor: TBD 132 132 133 ==== Shell Environment ==== 133 ==== Shell Environment ==== #shell-environment 134 134 135 Add 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`. 135 Add 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`. 136 136 137 Classification: medium task [[BR]] 137 This task alone is most probably not enough for the whole Summer Of Code. 138 139 Classification: easy task [[BR]] 138 140 Potential mentors: TBD 139 141 140 ==== Automatic testing ==== 142 ==== Automatic testing ==== #testing 141 143 142 144 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.