On Fri, 20 Sep 2002, Jeremy C. Reed wrote:

> I think it would be useful to have a small dependencies database that
> would contain information about all available built packages on the
> download sites (not just locally installed) and how they require each
> other.
>
> Then another tool could be used as a wrapper around pkg_add, for example,
> you choose to install koffice, then it would know what packages (with
> versions) are needed and then retrieve all of them first.
>
> I think this may provide another way to install software faster. (Any
> comments or suggestions?)

That does sound like a good idea. The tool really needs to run on the
server, so it can read the dependencies out of the packages without
downloading them (a cgi program)?

> Is there a pkgsrc target for showing the dependencies without the
> BUILD_DEPENDS too?

Irrelevant. The dependencies you would need to download are in
the binary packages. The dependencies in current pkgsrc are not
necessarily correct.

What would be neat, too, is if there were a tool that could pick out a
complete, nearly current set for 1.6-common from the 1.6, 1.6.1, (and
so on...), directories. That way, you could at least burn a CD that
didn't contain dozens of obsolete packages for every current one.

> It doesn't look like show-depends-dirs, show-all-depends-dirs-excl,
> show-all-depends-dirs, or show-root-dirs are documented.

They're utility targets, for use by the other targets. Why/where would
you document them?

> Is there a pkgsrc target for showing all (recursively) the dependencies
> without build dependencies that also shows the version information too?
>
> Something like "pkg_info -n"? (But without the results being based on the
> package information about already installed packages.)

What you see (in bsd.pkg.mk) is what you get. ;-)

> p.s. I had mentioned a few months ago about improving pkg_add so it could
> have an option to permanently save the retrieved file instead of just
> untarring it on the fly (as it is ftp'd). That way it could be used again
> from a local location (via PKG_PATH order) instead of fetching remotely
> again and again and again and ...

That sounds like a good idea, too.

> Anyways, I started patching various pkg_install files to add this feature.
> The pkg_install code is a little hard to follow :) I am guessing it would
> be better to rewrite a lot of the related code, instead of making
> additional add-ons.
>
>

Frederick