YAPIB (was: Drawing graphics on terminal)

[Paul Robinson]

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