Re: pkg_add and remote packages

[Dieter Baron <dillo%NetBSD.org@localhost>]

In article <47F68F28.7060006%pkgsrc.org@localhost> Johnny wrote:
: 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.

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

  That's nice, but the problem Joerg ran into also happens for single
package installs with specified version: finding out about missing
dependencies.  How does ruby gems handle that?

: 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? 

  It is:
    $ (for n in *.tgz; do pkg_info -X "$n"; done) | gzip -9 > pkg_summary.gz

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

  Hm, that would make it easier to update pkg_summary.  And it would
eliminate the need to download the whole thing for just installing one
package: download the *.pkg_summary file and you have the list of
dependecies.

  However, it would clutter up the package repository significantly.
I'm undecided wether I think it's worthwhile.

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

  That was one of the basic design criteria for pkg_summary.


: As for caching the fetched binary packages, perhaps we should just cache 
: them directly under ${PKG_DBDIR}, e.g. /var/pkg/packages/.

  Yes, that's what I meant.  But that caching should be optional,
since fetching across a local network is common enough.