YAPIB (was: Drawing graphics on terminal)

[Tim Kientzle]

Paul Robinson wrote:
> On Thu, Jun 19, 2003 at 09:42:20AM -0700, Tim Kientzle wrote:
>> * libtarfile works. ...
> ... the ability to look inside, if not packages, 
> at least tar files in memory ...
 >> * Direct package extraction works.  ...

In particular, I think that the work I'm doing now should
end the discussion about a "better" package format.  In short,
tar works quite well, thank you very much.  Past performance
issues were implementation problems, not format problems.

> Hah. OK, item number two on the list is struck off. Cool. Looks like I'll be 
> writing a GUI then? :-)

That would seem to be the hard part.  I presume you've
looked at SUSE's YAST, Debian's APT, and other such tools?

>> * Requirements handling:  I have some recursive requirements
>>   handling, but I'm not entirely happy with it. ...
> 
> I'd be interested to know why ...

What I have now works as follows:
  * Start reading the package, extract the packing list, parse it.
  * Identify any requirements, recursively install those.
  * Continue reading/installing this package.

This has a big problem with network installs.  In particular,
the download gets stalled while the requirements are added.
Over a slow connection, this could leave you with a stalled
TCP connection for hours.  Not good.

One way to address this would be to separate "install-time"
requirements from "run-time" requirements.  The ports framework
already has some concept of this (separates "build-time" from
"run-time"), but it doesn't seem quite sufficient.

I'm also looking at the 'INDEX' files that the package/ports
folks have long been maintaining.  By using that, I should
be able to generate a full requirements tree up front, then
install all of the necessary pieces in order without stalling.
Recursive handling will still be needed for installing package
files from disk, of course.

>> * 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 

I'm looking at a couple of approaches.  One is to eliminate -r and instead
have a simple list of package sources that get inspected.  Debian's package
management does something similar to this.  For example, you might have
an /etc/pkg.conf that specifies the following sources:
    .
    /usr/packages/distfiles
    /nfs-server/packages/distfiles
    ftp://ftp3.freebsd.org/some/path/packages-5.8-release/
    ftp://ftp.joesfreebsdsite.org/some/path/packages-5.8-release/
    cdrom:"FreeBSD 5.8 CDROM #2":/cdrom/packages
By pulling the INDEX data into a DB file, you should be able to
look up package locations very quickly indeed.  Since the INDEX
data includes requirements, you should be able to use this database
to expand any package request into a complete list of packages to be
installed.  In particular, note that this should allow us to support
the CD-ROMs more efficiently, by locating packages on particular CD-ROMs
and then prompting the user to insert the correct CD.

Note that this is simpler than having some form of "master redirect"
file, since each repository only needs to track what it provides,
not what other repositories might offer. Users can mix and match
repositories as needed.

> (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,

Just having the list of sources is enough.  From that, it's
easy to pull the INDEX files and generate the full DB.  The package
tools need to be able to update the DB periodically in any case.

> 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 ???

No opinion on this one.  Perhaps you could formulate a couple of
scenarios in which it would be beneficial to be able to mix and
match these two?

Tim