diff --git a/en/projects/ideas/ideas.xml b/en/projects/ideas/ideas.xml index fc96e99e58..e915e80aa2 100644 --- a/en/projects/ideas/ideas.xml +++ b/en/projects/ideas/ideas.xml @@ -15,7 +15,7 @@ Ideas//EN" - $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.14 2007/03/17 09:48:31 joel Exp $ + $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.15 2007/03/18 02:28:50 murray Exp $ @@ -1056,12 +1056,41 @@ of other syscalls.

+ + Collect the pkg-message output + + +

Technical contact: Pav Lucistnik

+ +

Collect the pkg-message output of dependencies and print them together + after the whole build finishes.

+ +

Details: Change the current ad-hoc way of including pkg-message in + the stdout of the build process. Automatically display pkg-message + in post-install, if present. For the dependencies, save the copies + of pkg-messages, as displayed in post-install, in /var/db/pkg, and + display them collectively once the whole build finishes. Also + allow for manual review by user later (new flag to + pkg_info(1)).

+ +

Requirements:

+ +
    +
  • Knowledge of shell and make coding, and basic overview of how + ports works.
    • +
  • Basic knowledge of C.
    • +
+ + + + COMPAT_43TTY

Technical contact: Gardner Bell

+ href="mailto:ed@fxq.nl">Ed Schouten

Some ports may break when removing COMPAT_43TTY from the kernel configuration since they assume old ioctl's when they identify FreeBSD. The goal of this entry is to:

@@ -1072,6 +1101,7 @@ of other syscalls.

from Kris Kennaway might also be good starting points.
  • Fix breakages and send patches upstream.
    • +

    Note: Ed is working on this. Please coordinate with him.

    Requirements:

    • Knowledge of autotools.
      • @@ -1134,6 +1164,102 @@ of other syscalls.

      + + Parallelization in the Ports Collection + + +

      Technical contact: Pav Lucistnik

      + +

      Add locking of write access to PKG_DBDIR (/var/db/pkg), to allow + several port builds run in parallel without clobbering the package + data. Should be done both in makefiles and in C tools like + pkg_install and pkg_delete. A simple flock(2) approach over the + whole database comes to mind.

      + +

      The next step is the parallelization of dependency building. Have + the port build it's dependencies in parallel, automatically + depending on number of CPUs in the machine, or manually specified + by user (make -j3 install clean). Some kind of split screen should + be devised, so user can easily watch the process and interact with + it (make config screens, for example). Attention must be paid to + prevent deadlocks.

      + +

      Allow for situation when two ports want to build and install + common dependency. One of the ports have to wait on the other to + install it before proceeding.

      + +

      And finally, unrelated to previous steps, but also desirable. Add + parallelization inside single builds, ie. enable -jX flag inside + vendor makefiles. This will allow us to exploit the power of + multi-core systems when building single port. Because a lot of + vendor code does not work correctly when built with -jX flag, some + kind of whitelist or blacklist must be implemented.

      + +

      Requirements:

      + +
        +
      • Strong knowledge of make and shell code.
        • +
      • Strong knowledge of C code.
        • +
      • Good understanding of the inner design of the Ports Collection.
        • +
      +       +       + + + UPDATING parser and displayer + + +

      Write a small C/shell app that will scan the installed ports and + show all UPDATING entries that affect one of the installed ports, + and are relevant on the given machine (ie. user haven't already performed the update). + Possibly the UPDATING format will have to be expanded to record the + versions of affected ports, like:

      + +

      gettext<0.16 -> gettext>=0.16

      + +

      The app will be used standalone, and called from pkg_version or + portupgrade.

      + +

      Requirements:

      +
        +
      • Basic shell/C coding.
        • +
      +       +       + + + Utility for safe updating of ports in base system + + +

      Also known as rewrite portupgrade in C.

      + +

      Write a new utility for the pkg_install suite, possibly named + pkg_upgrade(1), implementing a subset of existing portupgrade + functionality. The required functionality is:

      + +
        +
      • fixing @pkgdep records in +CONTENTS file
        • +
      • fixing +REQUIRED_BY records
        • +
      • storing old copies of shared libraries after shmajor number + change in /usr/local/lib/compat/pkg
        • +
      • upwards and downwards recursive modes
        • +
      + +

      Anything that existing portupgrade can do is a desired + functionality. It would be nice to be command line compatible with + portupgrade, but it's not a requirement.

      + +

      Requirements:

      + +
        +
      • Basic understanding of the Ports Collection design.
        • +
      • Good skills writing C code.
        • +
      • Ability to read Ruby will help.
        • +
      +       +       +