fun stats about pkg_*

[Marc Espie <espie_(_at_)_nerim_(_dot_)_net>]

wc output:

     630    1866   16239 pkg_add
     414    1215    8955 pkg_create
     209     683    5113 pkg_delete
     267     854    6094 pkg_info
     489    1438   11653 OpenBSD/Add.pm
      60     263    1837 OpenBSD/CollisionReport.pm
     416    1152    9783 OpenBSD/Delete.pm
     132     391    2446 OpenBSD/Error.pm
      58     152    1064 OpenBSD/Getopt.pm
      66     237    1474 OpenBSD/IdCache.pm
      48     217    1380 OpenBSD/Mtree.pm
     159     483    3279 OpenBSD/PackageInfo.pm
     432    1166    8306 OpenBSD/PackageLocator.pm
      73     262    1512 OpenBSD/PackageName.pm
    1246    2992   26870 OpenBSD/PackingElement.pm
     350     822    6578 OpenBSD/PackingList.pm
      50     190    1505 OpenBSD/PackingOld.pm
      68     263    1780 OpenBSD/PkgCfl.pm
     220     829    4720 OpenBSD/PkgSpec.pm
     120     376    2438 OpenBSD/ProgressMeter.pm
      68     273    1695 OpenBSD/RequiredBy.pm
     177     526    4363 OpenBSD/SharedItems.pm
      36     179    1160 OpenBSD/Temp.pm
     367    1012    8890 OpenBSD/Update.pm
     239     817    6127 OpenBSD/Ustar.pm
     209     667    4518 OpenBSD/Vstat.pm
      34     185    1148 OpenBSD/md5.pm
    6637   19510  150927 total

This is about the same size as the old C tools.
Slightly bigger if you don't count the signature code,
slightly smaller if you count it.

The code reorganisation shows lots of interesting stuff.
As expected, pkg_add/Add is the hard routine, even when lots of
things, like CollisionReport, or PkgSpec, or UStar
are into separate modules (conflict and dependency handling should
be more segregated as well, not 100% satisfying yet).

The package location (PackageLocator) code isn't very long yet, 
and it will grow in the future.

Update is deceptively small: it actually relies on most of
pkg_add/pkg_delete to work, and it became feasible only because
pkg_add/pkg_delete got properly reorganized first.

Shared items (directories and users/groups) are surprisingly easy to
handle.

The PackingElement code is growing a bit too much to my taste, I haven't
yet figured out how to cut pieces out... it is the heart of the new tools,
and thanks to its structure, one can perform heavy surgery on packages with
just a few lines of code. As an example, consider the code that tweaks 
all @pkgdep in an installed package from a $from package (old stuff) to 
an $into package (replacement):

sub adjust_dependency
{
        my ($dep, $from, $into) = @_;

        my $plist = OpenBSD::PackingList->from_installation($dep);
        my $items = [];
        for my $item (@{$plist->{pkgdep}}) {
                next if $item->{'name'} eq $from;
                push(@$items, $item);
        }
        $plist->{pkgdep} = $items;
        OpenBSD::PackingElement::PkgDep->add($plist, $into);
        $plist->to_installation();
}


Most functionality in there is new compared to the old tools:
Vstat is entirely new. Extraction on the fly from ustar archives is new.
Duplicating link info in the package is new. Smart handling of
dependencies, both forward and backward, is new. Specific handling of
shared libraries is new.

Seamless integration with the ports/ is ongoing: packing-lists automatic
updates work, automated checking of packages works...  building missing
packages from the ports tree does not work yet (or fetching missing binary
packages through ftp), but it's in my plans: we have all the necessary
information somewhere.

Like package signatures... like multi-architecture packages. All of these
have the necessary infrastructure. They're just missing a little bit of 
code.

Superficially, it looks like the old tools. Up to 3.6, it did behave like
the old tools.  Now it has started to grow...   still some way to go before
3.7.