tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_add and remote packages

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.   gems directory    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:


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/.


        -- Johnny C. Lam

Home | Main Index | Thread Index | Old Index