On Thu, Jun 19, 2003 at 09:42:20AM -0700, Tim Kientzle wrote:>> * Direct package extraction works. ...* libtarfile works. ...... the ability to look inside, if not packages, at least tar files in memory ...
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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
