Version 166 (modified by nerdling (Jeremy Lavergne), 14 years ago) (diff) |
---|
Google Summer of Code
-
Google Summer of Code
- Applications for SoC
- Mentors
-
Tasks
-
Core Tasks
- Binaries
- Check for software update / ports needing upgrade
- Scan for broken dynamic libraries for rebuild
- Dependencies
- Check dependencies after destroot
- MacPorts Port for self-management
- Perl modules integration from CPAN
- Automatic testing
- Configuration and environment selftest
- Improve startupitem code
- Dependency calculation during upgrade
- Reclaim disk space
- Parallel execution
- Trace mode
- Migrate muniversal into base (lipo merging)
- Fetching from version control
- Interactive port command
- Portfiles
- Shell Environment
- Additional tasks
-
Core Tasks
This is the main tracking page for MacPorts' Google Summer of Code.
Information about the past years can be found at SummerOfCodeArchive.
Applications for SoC
General Info
For future reference you may check the Google SoC website. You will find more information on their page on Advice for Students. The official 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 mailing list, to the potential mentors listed below, or to IRC members on #macports on 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 check out the code and read the guide.
- Read the Tcl Tutorial
- Subscribe to the mailing lists macports-dev and 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 2011 (append @macports.org for e-mail)
Name | Area | |
Rainer Mueller | raimue | Administrator |
William Siegrist | wms | Backup Administrator |
Jeremy Lavergne | snc | Mentor |
Perry Lee? | perry | Mentor |
Larry Gilbert | l2g | Mentor |
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
MacPorts project does not provide binaries yet (installation of pre-compiled software without compiling from source). This project consists of the setup of a chroot mechanism to automatically build packages, send reports on failures and implement a distribution mechanism to allow users to fetch compressed and signed binary packages. This task could extend to support universal binaries, multiple variants, and cross-testing (building on one box and testing on another).
This also includes to cleanly separate building software from installing it, by using binary archives. For this, a PkgIndex is needed that in addition to the PortIndex information also contains the binary versions needed and available. Additionally, a pkg(1) command could be developed that would allow to install from packages only without needing Xcode or the ports tree like port(1) does. The installations from binary (pkg add) should be able to cooperate with the installations from source (port install).
See also MacPorts AutoBuild.
Classification: relatively challenging to challenging task
Programming language: Tcl
Potential mentors: TBD
Check for software update / ports needing upgrade
The livecheck mechanism could be extended to automatically send reports when ports are outdated, similar to how the lint mechanism sends reports on portfile commits.
Classification: easy
Programming languages: Tcl
Potential mentor: TBD
Scan for broken dynamic libraries for rebuild
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
Programming languages: Tcl
Potential mentor: raimue
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: TBD
Check dependencies after destroot
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
Programming languages: Tcl and C
Potential mentor: raimue
MacPorts Port for 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
Programming languages: Tcl and C
Potential mentor: TBD
Perl modules integration from CPAN
There has been 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
Programming languages: Perl and probably Tcl
Potential mentor: TBD
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: raimue
Configuration and environment selftest
Add a command to check current setup for common pitfalls (e.g. stuff in /usr/local), inspired by 'brew doctor' from Homebrew.
Classification: easy
Programming languages: Tcl
Potential mentor: TBD
Improve startupitem code
MacPorts has the ability to automatically generate startup items for the current platform. For Mac OS X, these are plist files for launchd which will be installed as /Library/LaunchDaemons/org.macports.*.plist
. The current code would need a little care and could make use of options which have been added in recent releases of launchd.
Features that could be useful include (but are not limited to):
- Not using daemondo if the daemon works fine under launchd without it
- Ability to install multiple plists
- Support for LaunchAgents as well as LaunchDaemons
- Installing plists in ~/Library for non-root installs if the user wants
- only modify specific XML tags to avoid clobbering additions by user
Classification: easy
Programming languages: Tcl, C
Potential mentor: TBD
Dependency calculation during upgrade
Revamp the upgrade code to figure out (and optionally report) what it's going to do and detect conflicts etc. before it actually changes anything, and maybe even roll back to the original state if there's a failure
Classification: medium
Programming languages: Tcl, C
Potential mentor: TBD
Reclaim disk space
Improve 'port clean' to be able to delete distfiles for a specified version, and all distfiles not needed by currently installed versions of ports.
In general, add an action for reclaiming disk space, which would delete old distfiles and archives and uninstall inactive ports (and anything else that would help)
Classification: easy
Programming languages: Tcl, C
Potential mentor: TBD
Parallel execution
When an action will run targets on multiple ports, run them in parallel when possible and sensible (requires tracking dependencies between both targets and ports and figuring out the maximum reasonable parallelism, e.g. several ports can fetch at once on a fast connection but you only want one 'make -j8' at a time)
Classification: very challenging
Programming languages: Tcl, C
Potential mentor: TBD
Trace mode
Improve trace mode to the point where developers (and the build server) could run with it always turned on.
Classification: medium
Programming languages: Tcl, C
Potential mentor: TBD
Migrate muniversal into base (lipo merging)
Integrate muniversal into base. Not just a direct copy-and-paste, but in a way that makes sense and preserves the way portfiles are expected to behave (which the current portgroup doesn't).
Classification: medium
Programming languages: Tcl, C
Potential mentor: TBD
Fetching from version control
Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and then export into the work dir, to avoid having to re-fetch after cleaning the work dir. See #16373 for more information.
Classification: easy
Programming languages: Tcl, C
Potential mentor: TBD
Interactive port command
Write an interactive command-line tool that can be used instead of the non-interactive port(1).
The current port(1) should be viewed as batch mode reading from stdin.
An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. For example, if you try to install a port and one of its dependencies conflicts with something already installed, it could ask if you want to deactivate the installed one and its dependents.
Classification: medium
Programming languages: Tcl, C
Potential mentor: TBD
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: TBD
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
Potential mentors: raimue
Additional tasks
Task A1: Ports
- Porting of additional packages to MacPorts
- Cleanup and/or remove obsolete ports
Classification: medium task
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
Programming languages: php, python
Potential mentors: TBD