[MacPorts] SummerOfCode modified
MacPorts
noreply at macports.org
Mon Feb 3 14:36:35 PST 2014
Page "SummerOfCode" was changed by cal at macports.org
Diff URL: <https://trac.macports.org/wiki/SummerOfCode?action=diff&version=223>
Revision 223
Comment: Go over all proposals and refactor
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: SummerOfCode
=========================================================================
--- SummerOfCode (version: 222)
+++ SummerOfCode (version: 223)
@@ -97,30 +97,21 @@
* Languages: Tcl, C
* Potential mentors: cal
-==== Remove dependency on Xcode ==== #xcode
-
-MacPorts currently requires a full Xcode installation, even if the user
-only wishes to install prepackaged binaries or compile ports that do not
-use Xcode projects for building. This task be as simple as allowing
-MacPorts to install binary packages without Xcode present, or as complex
-as enabling MacPorts to be completely self-sufficient (not requiring
-Xcode or the Command Line Tools at all).
-
-* Difficulty: Medium to very challenging
-* Languages: Tcl, C
-* Potential mentors: TBD
+==== Phase out dependency on Xcode ==== #xcode
+
+MacPorts currently requires a full Xcode installation, even though a lot of ports will install just fine with the Command Line Tools package only. Since we also have a number of ports that need Xcode to build, we cannot completely remove the Xcode dependency. Your task would be to provide a way for maintainers to easily identify ports that depend on Xcode and mark them as such, so MacPorts can warn users without Xcode installed that a port they want to install needs the full Xcode package.
+
+To achieve this, you can modify "trace mode", a `DYLD_INSERT_LIBRARIES`-based sandbox to track whether a port has accessed files belonging to the Xcode package. If it does, your modifications should cause a warning to be printed suggesting the port maintainers to add `use_xcode yes` to the Portfile (unless of course, it is already there). You should also implement an error message if a user without Xcode installed tries to install a port that has `use_xcode yes` set.
+
+* Difficulty: Medium
+* Languages: Tcl, C
+* Potential mentors: cal
==== 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.
+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.
* Difficulty: Challenging
* Languages: Tcl, C
@@ -132,10 +123,7 @@
===== 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.
+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
@@ -148,19 +136,11 @@
===== Read packages from Python's PIP (pip2port) ===== #pip2port
-MacPorts should be able to more readily install python packages from
-pip. We don't want to integrate the build/installation process of PIP,
-simply parse information or eggs it provides for various packages. This
-information will then be used to generate a Portfile, akin to
-[[browser:contrib/cpan2port/cpan2port|cpan2port]].
-
-There may be instances where MacPorts package names don't match up with
-pip’s. In this case, pip should be the authority and all improperly
-named MacPorts packages should be replaced by a renamed copy. Verbose
-automation of this step, akin to the portcheckup script, is ideal.
-
-The [[browser:contrib/portfile-gen/portfile-gen|portfile generator]]
-might be helpful.
+MacPorts should be able to more readily install python packages from pip. We don't want to integrate the build/installation process of PIP, simply parse information or eggs it provides for various packages. This information will then be used to generate a Portfile, akin to [[browser:contrib/cpan2port/cpan2port|cpan2port]].
+
+There may be instances where MacPorts package names don't match up with pip’s. In this case, pip should be the authority and all improperly named MacPorts packages should be replaced by a renamed copy. Verbose automation of this step, akin to the portcheckup script, is ideal.
+
+The [[browser:contrib/portfile-gen/portfile-gen|portfile generator]] might be helpful.
* Difficulty: Medium
* Languages: Tcl, Python, C
@@ -168,10 +148,7 @@
===== Read packages from other various package managers ===== #foo2port
-As above with the pip2port proposal, except with other package managers,
-such as [http://opam.ocamlpro.com/ opam] for ocaml packages,
-[http://www.haskell.org/cabal/ cabal] for haskell, [http://luarocks.org/ luarocks]
-for lua, [https://npmjs.org/ npm] for node.js, and so on.
+As above with the pip2port proposal, except with other package managers, such as [http://opam.ocamlpro.com/ opam] for ocaml packages, [http://www.haskell.org/cabal/ cabal] for haskell, [http://luarocks.org/ luarocks] for lua, [https://npmjs.org/ npm] for node.js, and so on.
* Classification: Medium
* Languages: Tcl, C, OCaml, Haskell, Lua, Node.js, etc.
@@ -181,7 +158,7 @@
To ease creation of new ports, the helper script [http://trac.macports.org/browser/contrib/portfile-gen/portfile-gen portfile-gen] is able to generated a Portfile stub by taking the name, version and possible a port group as input. This should be extended to handle more things automatically. Lots of options in a Portfile need to be figured out by the maintainer, although they could be extracted automatically from the source.
-With just a URL to the tarball of a software, portfile-gen can usually automatically extract the name and the version from the filename. Furthermore, the master_sites and distfiles can be derived from the URL, with special handling for sites like sourceforge/gnu/etc. However, it should also be possible to specify this later and start portfile-gen with a pre-downloaded tarball. The checksums for the distfiles can be generated after fetching the tarball (portfile authors should be warned to verify these with upstream!) and even more information can be collected when extracting the tarball.
+With just a URL to the tarball of a software, portfile-gen can usually automatically extract the name and the version from the filename. Furthermore, the master_sites and distfiles can be derived from the URL, with special handling for sites like sourceforge/gnu/github/etc. However, it should also be possible to specify this later and start portfile-gen with a pre-downloaded tarball. The checksums for the distfiles can be generated after fetching the tarball (portfile authors should be warned to verify these with upstream!) and even more information can be collected when extracting the tarball.
Different build systems usually have a unique way to be detected. For example, if a `configure.ac` or `configure.in` exists, but no `configure`, we need to run autoconf. If there is also a `Makefile.am`, but no `Makefile.in` this is using automake and we should better use `autoreconf` instead. If there is a `CMakeLists.txt`, we should include the cmake port group. If there is just a Makefile, but no `configure`, chances are high we can skip the configure phase with `use_configure no`.
@@ -193,36 +170,19 @@
* Languages: Tcl
* Potential mentors: raimue
-==== Increase test coverage ==== #testing
-
-MacPorts currently includes a [[source:trunk/base/tests|test framework]]
-to test features of the infrastructure. However, the tests do not cover
-all the code. 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.
-
-* Difficulty: Relatively easy to very challenging
-* Languages: Tcl, C
-* Potential mentor: raimue
-
==== Configuration and environment selftest ==== #envcheck
-Add a command to check current setup for common pitfalls (e.g. stuff in
-`/usr/local`), inspired by Homebrew’s `brew doctor` functionality.
+Add a command to check current setup for common pitfalls (e.g. stuff in `/usr/local`), inspired by Homebrew’s `brew doctor` functionality.
* Difficulty: Easy
* Languages: Tcl
* Potential mentors: larryv
-==== Improve Trace mode ==== #tracemode
-
-Improve trace mode to the point where developers (and the build server)
-could run with it always turned on. This currently requires fixing some
-(minor) remaining bugs in the trace code itself, adjust the build system
-to always build the tracing library as universal binary and improving
-the Tcl backend of trace mode (e.g. by adding more features like a list
-of accessed files, speeding up the lookup by using better data
-structures).
+==== Speed up trace mode ==== #tracemode
+
+Trace mode is a library preloading-based sandbox used to hide files that a port does not depend on or that are not part of a standard system's installation (such as `/usr/local`). This can avoid problems due to incompatible user-installed software and avoid "automagic" dependencies and increase the reproducibility of builds.
+
+Unfortunately, enabling trace mode adds a significant performance penalty to the build process. However, the trace mode code can certainly be optimized using appropriate cache data structures, such as a modified [http://en.wikipedia.org/wiki/Trie Trie]. Your task would be to identify the performance bottle necks, draft appropriate caching data structures and implement them.
* Difficulty: Medium to Easy
* Programming languages: Tcl, C
@@ -230,18 +190,14 @@
==== Improve startupitem code ==== #startupitem
-MacPorts has the ability to automatically generate startup items for the
-current platform. For 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.
+MacPorts has the ability to automatically generate startup items for the current platform. For 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
+ - 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
* Difficulty: Easy
* Languages: Tcl, C
@@ -249,11 +205,7 @@
==== Reclaim disk space ==== #reclaim
-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).
+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). Implement heuristics to detect common hogs of disk space such as lots of old distfiles and inactive ports and periodically suggest running a cleanup command to users if such possibly unneeded files are detected.
* Difficulty: Easy
* Languages: Tcl, C
@@ -261,23 +213,15 @@
==== Parallel execution ==== #parallel
-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).
-
-* Difficulty: Very challenging
+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).
+
+* Difficulty: Challenging
* Languages: Tcl, C
* Potential mentors: TBD
==== Migrate muniversal into base (lipo merging) ==== #muniversal
-Integrate the
-[[source:trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl|muniversal portgroup]]
-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).
+Integrate the [[source:trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl|muniversal portgroup]] 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).
* Difficulty: Medium
* Languages: Tcl, C
@@ -285,8 +229,7 @@
==== Improve fetching from version control ==== #fetchtypes
-Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and
-then export into the work dir, to [[ticket:16373|avoid having to re-fetch]]
+Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and then export into the work dir, to [[ticket:16373|avoid having to re-fetch]]
after cleaning the work directory.
* Difficulty: Easy
@@ -295,32 +238,19 @@
==== Interactive port command ==== #interactive
-Write an interactive command-line tool that can be used instead of the
-non-interactive port(1). (The existing "interactive mode" of port(1) is actually just batch
-mode reading from stdin, and is not really interactive.)
-Factor out code used by both tools into a shared module.
-
-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.
+Write an interactive command-line tool that can be used instead of the non-interactive port(1). (The existing "interactive mode" of port(1) is actually just batch mode reading from stdin, and is not really interactive.) Factor out code used by both tools into a shared module.
+
+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.
* Difficulty: Medium
* Languages: Tcl, C
* Potential mentors: TBD
-
=== Secondary tasks ===
==== 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. This might also
-include porting additional packages to MacPorts and cleaning up or
-removing obsolete ports.
+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. This might also include porting additional packages to MacPorts and cleaning up or removing obsolete ports.
* Classification: Medium
* Language: Tcl
@@ -328,9 +258,7 @@
==== Documentation and website ==== #docs
-Improve MacPorts
-[query:status!=closed&component=guide|server/hosting|website|wiki documentation, website and Trac system].
-Note that pure documentation proposals are not allowed by Google.
+Improve MacPorts [query:status!=closed&component=guide|server/hosting|website|wiki documentation, website and Trac system]. Note that pure documentation proposals are not allowed by Google.
* Difficulty: Easy to difficult
* Languages: PHP, Python
@@ -338,12 +266,7 @@
==== 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`.
+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.
@@ -365,21 +288,6 @@
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
}}}
-------8<------8<------8<------8<------8<------8<------8<------8<--------
--
Page URL: <https://trac.macports.org/wiki/SummerOfCode>
MacPorts <http://www.macports.org/>
Ports system for OS X
This is an automated message. Someone added your email address to be
notified of changes on 'SummerOfCode' page.
If it was not you, please report to .
More information about the macports-changes
mailing list