YAPIB (was: Drawing graphics on terminal)

Tim Kientzle kientzle at acm.org
Thu Jun 19 09:41:17 PDT 2003


Paul Robinson wrote:
> As to what I'm writing, well, I'm going to do the design in about four weeks 
> time, and anybody who is interested can take a look. An announcement will 
> probably go up on -hackers and -libh...
> ....
> I want something that works. To be honest, just something that abstracts 
> /usr/ports and makes use of the pkg-descr files would be more useful than 
> the current blank void navigated with cd and more...


Paul,

When you get ready to do some work, let me know.  I've
been rewriting the guts of pkg_add for the last month
or two.  I'm pretty pleased with the results so far,
but there's still a lot of code to write.

So far:
  * libtarfile works.  This is a library that provides
    simple iteration over tarfiles.  It handles format
    detection (e.g., both old/Posix/GNU formats and
    gzip/bzip2/etc compression), can 'extract' entries
    to disk or to an in-memory buffer, etc.  The read support
    is pretty solid; the write support is just a sketch.
  * Direct package extraction works.  I can open a package
    file from stdin, disk, ftp, etc, and just install it
    without having to create a temp directory or any of
    that nonsense.  The idea: extract the packing list
    into memory, parse it, use it to direct the extraction
    of the rest of the package.  This is _MUCH_ faster
    than the older pkg_add code.
  * I've also completely overhauled the packing-list
    parsing code and a lot of the other basic operations.

Next steps:
  * Requirements handling:  I have some recursive requirements
    handling, but I'm not entirely happy with it.  I'm exploring
    other approaches.
  * Locating packages.  This will probably involve building
    a DB file in /var/db/pkg to record information about
    what packages are available from which ftp sites, etc.
  * Handling conflicts gracefully.  This may well involve
    building a DB file that maps filenames->package names
    so that an attempt to overwrite a file can be immediately
    tracked back to the conflicting package.
  * Building a useful library.  I'm being careful to keep code
    as generic as possible, so it should be pretty simple
    to put a lot of the useful pieces (packing-list management,
    locating packages, etc) into a library.

Like I said, let me know when you're ready to work on this.
My stuff is still pretty rough in some spots, but a lot of
it should prove useful to anyone working on install issues.

Tim Kientzle



More information about the freebsd-libh mailing list