On Mon, 4 Nov 2002, Jeremy C. Reed wrote:

> On Mon, 4 Nov 2002 grant@netbsd.org wrote:
>
> > >Synopsis:       pkg_* tools should be smarter about reading binary packages
>
> I agree.
>
> > It should not be necessary to read the entire package to query it.

I thought the current pkg tools did that already (using --fast-read)?

> It would be useful to have a single download that contains some info about
> all the available packages (for an architecture and a release or
> -current).
>
> Then it would be easier to know some basic information about other
> packages including required dependencies.
>
> In addition, this could make software installations and upgrades very
> easy. For example, you want to upgrade to some package so you can have an
> instant tsorted list of dependencies (which you already know are
> available). And this can be compared with already installed software. Then
> the software can be uninstalled (as needed), required packages downloaded
> and installed in order.

I agree. "pkg_add" would be too overloaded, but something like the
cygwin installer and companion cgi scripts on the server would be a
good thing. In the past (1.5), it wouldn't have been possible to come
up with a path through the graph even with perfect information,
because of the way packages were made. Now that we're a lot more
careful that packages with the same version number have the same
dependencies, it may be possible to do this for the 1.6 collection,
and later collections.

Note that it's not a trivial task. We don't even have a method yet to
order "pkgsrc" packages at build time (although I've started on it,
but all I have to present so far is a man page:

  ftp://ftp.netbsd.org/pub/NetBSD/misc/fredb/pkgorder.1

), and the binary package problem, where each version of each package
can potentially have different dependencies, is that much more
complicated.

I have this idea to one-up the cygwin installer (which presents
exactly three solutions: all previous versions, all "current", and all
development). The client would display a two-dimensional graph;
rolling over a node would highlight the package and display the
comment and description in a box; clicking on a node would open up a
stack of alternatives, and choosing one re-arranges the rest of the
graph. Additionally, there'd be buttons along the side or bottom for
"latest of everything", "minimal change", and probably others. There'd
be another box for the script(s) that the chosen configuration would
need to run (involving "ftp" and "pkg_add"), and a button to save them
as a file, because I doubt that NetBSD'rs would be happy to run a
graphical client as root.

Frederick