- Yank two ports related ideas that were largely finished in previous years but

haven't been yet committed
This commit is contained in:
Pav Lucistnik 2010-04-02 09:28:32 +00:00
parent 122fe3d6fd
commit 977d29ca59
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=35608

View file

@ -15,7 +15,7 @@ Ideas//EN"
<ideas>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.160 2010/03/28 16:25:50 rwatson Exp $
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.161 2010/03/30 21:36:21 rwatson Exp $
</cvs:keyword>
</cvs:keywords>
@ -1242,31 +1242,6 @@ href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.
<category>
<title>Ports</title>
<idea id="ports-db" class="soc">
<title>Add .db support to pkg_tools</title>
<desc>
<p>pkg_create(1) and friends use flat databases (aka ordinary
files and directories in /var/db/pkg) to maintain their data. This
makes it cumbersome and/or impossible to do efficient lookups of data
on installed packages and makes certain operations very slow.
portupgrade has the right idea of hashing this into a berkeley db
file, but it uses tools that are not in the base system (ruby).</p>
<p>A self-contained project would be to add similar (preferably
compatible) code into pkg_tools directly, possibly also extending
the data that is stored and allowing for more flexible querying with
tools like pkg_info (e.g. replicating the pkg_which utility of
portupgrade). Adding mutual exclusion to protect concurrent
pkg_add/delete operations from corrupting database state is also
important.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Knowledge of C.</li>
<li>Basic understanding of the use of berkeley db.</li>
</ul>
</desc>
</idea>
<idea id="ports-pkgtools">
<title>Package tools improvements</title>
@ -1283,38 +1258,6 @@ href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.
</desc>
</idea>
<idea class="soc" id="ports-parallel">
<title>Parallelization in the Ports Collection</title>
<desc>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of make and shell code.</li>
<li>Strong knowledge of C code.</li>
<li>Good understanding of the inner design of the Ports Collection.</li>
</ul>
</desc>
</idea>
<idea id="fat-pkgs" class="soc">
<title>Complete (a.k.a. Fat) packages</title>
<desc>