From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 11:24:40 2003 Return-Path: Delivered-To: freebsd-libh@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47DCB37B401; Thu, 19 Jun 2003 11:24:40 -0700 (PDT) Received: from mail1.qc.uunet.ca (mail1.qc.uunet.ca [198.168.54.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3102443FBF; Thu, 19 Jun 2003 11:24:39 -0700 (PDT) (envelope-from anarcat@espresso-com.com) Received: from xtanbul.studio.espresso-com.com ([216.94.147.57]) by mail1.qc.uunet.ca (8.12.9/8.12.9) with ESMTP id h5JILqsB006773; Thu, 19 Jun 2003 14:21:52 -0400 Received: from anarcat by xtanbul.studio.espresso-com.com with local (Exim 3.36 #1 (Debian)) id 19T42i-0000HT-00; Thu, 19 Jun 2003 14:21:52 -0400 Date: Thu, 19 Jun 2003 14:21:52 -0400 From: The Anarcat To: Tim Kientzle Message-ID: <20030619182151.GA1074@xtanbul> Mail-Followup-To: The Anarcat , Tim Kientzle , Paul Robinson , Samy Al Bahra , freebsd-hackers@freebsd.org, freebsd-libh@freebsd.org References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <20030616191852.GA52694@ussenterprise.ufp.org> <20030618100125.GP20204@iconoplex.co.uk> <1055948691.92188.10.camel@beastie.freebsd.local> <20030618154012.GE533@xtanbul> <20030619095739.GC20204@iconoplex.co.uk> <3EF1E7EC.3040908@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF1E7EC.3040908@acm.org> User-Agent: Mutt/1.5.4i Sender: The Anarcat cc: freebsd-libh@freebsd.org cc: Paul Robinson cc: Samy Al Bahra cc: freebsd-hackers@freebsd.org Subject: Re: YAPIB (was: Drawing graphics on terminal) X-BeenThere: freebsd-libh@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 18:24:40 -0000 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 >