Date: Thu, 19 Jun 2003 18:07:42 +0100 From: Paul Robinson <paul@iconoplex.co.uk> To: Tim Kientzle <kientzle@acm.org> Cc: freebsd-hackers@freebsd.org Subject: Re: YAPIB (was: Drawing graphics on terminal) Message-ID: <20030619170742.GO20204@iconoplex.co.uk> In-Reply-To: <3EF1E7EC.3040908@acm.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 19, 2003 at 09:42:20AM -0700, Tim Kientzle wrote: > When you get ready to do some work, let me know. I've Will do. Just need to move, get DSL installed, and clear down some work and I'm looking at a year of clear weekends and evenings. And this is biting me up inside now... :-) > * 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. v. cool. The other night when I was sitting in the pub sketching on beer mats and cigarette packets to work out what needed doing, one of the first things that sprung to mind was the ability to look inside, if not packages, at least tar files in memory just to get the juicy info out to present the user with choices as to whether that pkg is something they really want, and if so, not have to play around in /tmp or wherever... > * 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. Hah. OK, item number two on the list is struck off. Cool. Looks like I'll be writing a GUI then? :-) > * Requirements handling: I have some recursive requirements > handling, but I'm not entirely happy with it. I'm exploring > other approaches. I'd be interested to know why you're not happy with it - is it the concept of recursiveness over a set of requirements in general you think is flawed, or is it your implementation which is niggling you? Requirements and dependancy tracking/handling are big issues. I've resorted to reading papers on how people have approached it in the past and have some vague ideas, and recursiveness has problems. Recursiveness is always problematic though, no matter what domain you take it too - branching is where I was thinking. > * 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. Instead of retrieving the binary when you do a pkg_add -r perhaps you could end up grabbing a file that described where it could *really* be found (thereby alleviating mirrors from carrying GBs of packages, just the descriptions of where they are), including possible locations on disk, and ultimately, ports ... nothing stopping you shipping this db as part of the base install, or like ports is now, but then we get to crux: Shouldn't pkg_add be an abstraction of ports, with the advantage of grabbing a pre-built binary if it's available, with a command line switch to force a traditional cd /usr/ports/category/package; make install clean ??? At the moment we have ports, and we have packages. Maybe it's time to merge to the benefit of both? <hides under flameproof blanket> <snip> > 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. Yeah, certainly, thanks for the heads up. I'm sure I would have been hassling you in a fortnight anyway. :-) -- Paul Robinson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030619170742.GO20204>