Hi all,
since the mid-project evalution is on the doors, I want to summarize the
current status of the pkg_install project.

(1) Dependency handling
I have proposed a unified new format (first version:
http://mail-index.netbsd.org/tech-pkg/2006/05/24/0007.html, refined
syntax in
http://netbsd-soc.sourceforge.net/projects/pkg_install/doc/pkg_install.html
which also has a number of test cases in the CVS repository). This is
meant to address the short comings of the current mix of Dewey, fnmatch
and alternative matching, which creates problems as e.g. mentioned in
http://mail-index.netbsd.org/tech-pkg/2006/05/23/0004.html.

This subproject is mostly finished. A full description of syntax and
semantic exist, the library interface is finalised and a full
implementation will be published over the next few days. I have investigated
the possibilties for automatic conversions of the old dependency style to
the new style. For the state of the branch tree, around 35 patterns
currently need manual intervention, the rest can be converted fully
automatically to semantically mostly equivalent patterns. Further
details are available on request.

Two items are still have to be covered:
- Reduction and merging of dependencies. A detailed write-up of this
topic will follow soon to this list, the mail from May linked above is a
good introduction.
- OpenBSD "flavor" like support for optional features and the matching
on the presence/absence of an option. This topic won't be covered until
rules for including options in the package name are created.

(2) Package meta-data
I have thought about three relatively isolated parts of the meta-data
problem and proposed possible solutions. Since the desired functionality
is not finished, the implementation or interface design has not started
yet.

- To handle the problem of redundant INSTALL/DEINSTALL scripts and
simplify the maintaince, a trigger mechanism was proposed. See
http://mail-index.netbsd.org/tech-pkg/2006/06/22/0004.html for the
general idea. The related topic of depending on the provision of an
implementation of a certain feature was discussed, but no consensus
reached so far.
- The fundamental question of the content of a package based on the file
list was rised (http://mail-index.netbsd.org/tech-pkg/2006/07/02/0006.html).
A number of functions of the current PLIST should be eliminated (devices
in packages, @dirrm, @exec/@unexec). Directory handling should be mostly
automated and permissions explicitly included just like the checksums.
This means moving a lot of the functionality of the install scripts back
into the pkg tools.
- The implementation of update functions needs to be improved to catch
up e.g. to certain Linux distributions. Explicit compatiblity entries
have been suggested to handle this
(http://mail-index.netbsd.org/tech-pkg/2006/07/02/0027.html)

Remaining issues in this area are a walk through the currently generated
information and a classification thereof. Since the most critical items
have been handled separately, this is a relatively straight forward
process. Once the discussion for the former mentioned items has settled
down, I will work on the API and the storage format specification. The
general API structure of the dependency implementation will be continued
for this. Target for both is the middle of July. With the finalised
initial specs, the work on the regression suit will start. This is
supposed to cover the rest of July.

(3) pkgsrc integration
Based on the output of the new bulk build system (stay tuned for that),
I have started to make the patterns in the tree more friendly for the
conversion, as mentioned earlier. This will continue and I am
investigating whether or not the new dependency scheme can be integrated
directly into the current pkg_install without breaking backwards
compatibility. This would simplify the task of converting the tree by
allowing an incremental approach and exploit the time of other
developers. Related to the automatic reference counting for directories
is the detection and eliminition of mtree users in the tree.
The rest of the package descriptions are hopefully in a descriptive
enough format, so that they can be converted without human intervention.


Since the 2006Q2 branch is out, I can spend a lot more time on actually
writing code for this project over the next week, so the progress should
increase a lot.

Joerg