YAPIB (was: Drawing graphics on terminal)
Tim Kientzle
kientzle at acm.org
Thu Jun 19 09:41:16 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-hackers
mailing list