YAPIB (was: Drawing graphics on terminal)

The Anarcat anarcat at anarcat.ath.cx
Thu Jun 19 11:24:40 PDT 2003


Bravo!

Now this is the talk I like to hear. :)

Sorry to have been so negative in my last emails, I see there is good
work going on. I have forgotten about you efforts, Tim.

Don't give up!

A.

On jeu jun 19, 2003 at 09:42:20 -0700, Tim Kientzle wrote:
> 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