Dieter Baron wrote:
If we required a up-to-date pkg_summary, you could use this to extract the dependency tree before fetching anything. This would also catch wether the package or one of its dependencies would cause conflicts with the currently installed packages and abort early. I think this is the way we should eventually go. Just a random thought (don't know how practical/efficient/useful it is): You could abort the data connection after you fetched the metadata and found missing dependencies, then refetch afterwards (possibly resuming where you left off).
For comparison, I offer the the experiences I've recently had with Rubygems installation and distribution. All gem repositories have a standard format.
http://gems.foo.org/gems/ gems directory
http://gems.foo.org/yaml YAML description of available gems
If you ask the "gem" tool to install a particular remote gem by name
*and* version, then it grabs it directly from the gems directory.
Otherwise, it grabs the YAML file to see what gems are available and
which match the name given and offers the user the choice of different
version to install.
This standard format for the repositories is good -- in fact, practically any installed set of gems on your own system can be used directly as a gem repository for other users. The YAML file referenced here corresponds to the pkg_summary file you mentioned, and I think it's a good idea to require that it be generated for remote package repositories. Is it possible to make the summary file easy to generate? Perhaps a binary package should consist of two files in the package directory:
packages/foo-1.0.tar.gz
packages/foo-1.0.pkg_summary
These two files can be generated automatically by "make package". Then
to create the "global" pkg_summary file, you just concatentate all of
the *.pkg_summary files together. The *.pkg_summary files should also
be something that can be generated from data within the .tar.gz file in
case it's not present so that a package repository admin can run a tool
to create the missing *.pkg_summary files.
As for caching the fetched binary packages, perhaps we should just cache them directly under ${PKG_DBDIR}, e.g. /var/pkg/packages/.
Cheers,
-- Johnny C. Lam